[Bug 2108997] Re: [UBUNTU 22.04] GDB: Internal binutils code requires updates made for IBM z17 in binutils already
Frank Heimes
2108997 at bugs.launchpad.net
Fri Jun 13 14:56:48 UTC 2025
Thank you, juliank, for looking at this request.
I agree that the impact section could be expanded.
It's actually about having this as part of a larger set of updates, that all have the goal in common to enable the latest Ubuntu LTS release for the latest s390x hardware generation, hence seeing this as a hwe SRU.
Systems like the new z17 are designed for long running workloads, hence a non-LTS Ubuntu version is not properly suited for production workloads, hence users/customers/partners want to use an Ubuntu LTS.
However, 25.04 is the first Ubuntu release that comes with full support for z17.
Ubuntu, incl. latest LTS, can already be installed on this hardware, but only in toleration mode.
But it's important and desired to be able to exploit the latest hardware generation, means building code for it, but also maintaining and potentially debugging it.
Hence, the modifications in binutils/gdb (which is part of a bigger hwe effort).
Without this no proper z17 code life-cycle management (incl. debugging) is possible and opcodes might be unknown.
(I've added this to the SRU description.)
The request came in to apply only commit eeafc61979c6.
But this commit alone only applies to plucky as-is.
And in case of plucky I think that the risk for regressions is relatively moderate, since it mainly adds to the opcodes "z17" in addition to the already existing "arch15".
Regressions are still possible, for example if the statements are not properly expanded with ANDs or ||s, but this is testable and covered by the test plan.
For oracular (which could probably be skipped now, because we are very close to it's end of live anyway) and for noble, two more commits are needed. This definitely increases the potential risk of regressions,
but these commits actually add the "arch15" it's corresponding code, before making "arch15" also known as "z17", like in plucky.
Commit a98a6fa2d8ef adds code and opcodes,
hence this will ideally not be harmful for older hw generations.
And commit a3f1e7c56a60 introduces a simplification on how operands are handled with const bits. The latter one is already included in oracular and plucky, so established and tested there, and all this is limited to the s390x architecture, and the request for adding these commits comes from the architecture owner.
The majority of risk is in this later commit, and it could be helpful to mitigate this with further test cases.
(Added this as well.)
The patch set for jammy increased even more, and I was not happy seeing this - I think it could be discussed if modifying jammy is really needed (in case the patches can at least land in 24.04, so that one LTS is covered), or if the patches can be shrinked further down.
For now I'm changing the jammy entry to 'opinion'.
** Description changed:
SRU Justification:
[ Impact ]
- * This is a hardware enablement SRU.
+ * Systems like the new z17 are designed for long running workloads,
+ hence a non-LTS Ubuntu version is not properly suited for production
+ workloads, hence users/customers/partners want to use an Ubuntu LTS.
+ However, 25.04 is the first Ubuntu release that comes with full
+ support for z17.
+
+ * Ubuntu, incl. latest LTS, can already be installed on this hardware,
+ but only in toleration mode.
+ But it's important and desired to be able to exploit the latest
+ hardware generation, means building code for it, but also maintaining
+ and potentially debugging it.
+ Hence, the modifications in binutils/gdb
+ (which is part of a bigger hwe effort).
+ Without this no proper z17 code life-cycle management (incl. debugging)
+ is possible and opcodes might be unknown.
+
+ * With the above I believe that this corresponds to a hardware
+ enablement SRU.
* It introduces support for the new IBM z17 hardware to binutils.
* Some Ubuntu releases (like plucky) have already 'anonymous' support
for in terms of 'arch-15', other Ubuntu releases have no 'arch-15' nor
z17 support at all and require two more patches.
- * Without this binutils not not aware about the new z17 hardware generation
+ * Without this binutils are not aware about the new z17 hardware generation
and it's opcodes etc.
[ Fix ]
- * eeafc61979c6f8399bb5ce770e46a00823a5cfae ("s390: Make operand table
+ * eeafc61979c6f8399bb5ce770e46a00823a5cfae ("s390: Make operand table
indices relative to each other") - pre-req. for jammy only
* a3f1e7c56a60573562e8578ae8b675ec1f4448e7 ("s390: Simplify
(dis)assembly of insn operands with const bits") - pre-req. for jammy,
noble and oracular
* a98a6fa2d8ef5eb61534b07db80850dcdf07bdb4 ("s390: Add arch15
instructions") - pre-req. for jammy, noble and oracular
- * 981fe5fd80faf511aa265e841a380c9b46be30e6 ("390: Add support for z17
- as CPU name")
+ * < 981fe5fd80faf511aa265e841a380c9b46be30e6 ("390: Add support for z17
+ as CPU name") >
[ Test Plan ]
* Check if the same (proper) opcodes are detected on an IBM z17
system with and without the patch.
Since the identification and name of a z17 system was added.
* Or the simplest test is probably to check
(after having 'binutils' installed on an
Ubuntu Server 25.04, 24.10 or 24.04 s390x system)
if not only:
'as -m64 -march=arch15 --target-help'
but especially also:
'as -m64 -march=z17 --target-help'
succeeds and leads to the same output.
(As it does for '-march=arch14' and '-march=z16'.)
* Due to the lack of hardware this needs to be tested at IBM.
[ Where problems could occur ]
- * The new name could be wrong, or the name could be accidentally
- mapped to the wrong internal arch.
- (The test case above will allow to identify this by comparing the output.)
+ * The request came in to apply only commit eeafc61979c6.
+ But this commit alone only applies to plucky as-is.
+ And in case of plucky I think that the risk for regressions is
+ relatively moderate, since it mainly adds to the opcodes "z17"
+ in addition to the already existing "arch15".
- * The two pre-required patches could cause harm - the simplification
- and the introduction of the internal arch-15 itself.
- These are only needed for oracular and older,
- and are included in binutils for a while.
+ * Regressions are still possible, for example if the statements are
+ not properly expanded with ANDs or ||s, but this is testable
+ and covered by the test plan.
- * Other architectures are not touched and affected, since only s390x
- specific files are modified (except the doc file as/doc/as.texi on top).
+ * On top the new name could be wrong, or the name could be accidentally
+ mapped to the wrong internal arch.
+ (The test plan above will allow to identify this and the previous bullet.)
+
+ * For oracular (which could probably be skipped now, because we are
+ very close to it's end of live anyway) and for noble, two more
+ commits are needed. This definitely increases the potential risk of
+ regressions.
+
+ * But add. commits add the actual "arch15" and it's corresponding code,
+ before then making "arch15" also known as "z17" (1st commit).
+
+ * Commit a98a6fa2d8ef only adds code and opcodes,
+ hence this will ideally not affect any older hw generations.
+
+ * Commit a3f1e7c56a60 however introduces a simplification on how
+ operands are handled with const bits.
+ But this is already included in oracular and plucky, so it's there
+ as well as upstream established and tested.
+
+ * In addition all this is limited to the s390x architecture
+ (except the doc file as/doc/as.texi),
+ and will cause no harm for any other architecture,
+ and the request for adding these commits is coming from the
+ architecture owner.
+
+ * Anyway, the majority of risk is in this later commit, and it could
+ be helpful to mitigate this with further test cases.
[ Other Info ]
* binutils maintainer (doko) told me that binutils for questing
will be updated anyway to latest release/snapshot,
so nothing to do for questing in this LP bug (and set to Invalid).
+
+ * Due to the proximity of oracular's end of life,
+ the SRU to oracular might be skipped.
+
+ * Due to the growing amount of changes that are needed for jammy
+ I updated the status to 'Opinion'.
__________
With IBM having announced the new IBM z17, Ubuntu 22.04 and 24.04 should
be enabled to run properly on the latest s390x hardware.
While plucky has already the required patches included, please backport
to noble and jammy the GNU Binutils mainline commit 981fe5fd80fa ("s390:
Add support for z17 as CPU name"), which adds the real CPU name "z17" as
alternative for "arch15".
** Changed in: binutils (Ubuntu Jammy)
Status: In Progress => Opinion
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/2108997
Title:
[UBUNTU 22.04] GDB: Internal binutils code requires updates made for
IBM z17 in binutils already
Status in Ubuntu on IBM z Systems:
In Progress
Status in binutils package in Ubuntu:
Invalid
Status in binutils source package in Jammy:
Opinion
Status in binutils source package in Noble:
In Progress
Status in binutils source package in Oracular:
In Progress
Status in binutils source package in Plucky:
Incomplete
Status in binutils source package in Questing:
Invalid
Bug description:
SRU Justification:
[ Impact ]
* Systems like the new z17 are designed for long running workloads,
hence a non-LTS Ubuntu version is not properly suited for production
workloads, hence users/customers/partners want to use an Ubuntu LTS.
However, 25.04 is the first Ubuntu release that comes with full
support for z17.
* Ubuntu, incl. latest LTS, can already be installed on this hardware,
but only in toleration mode.
But it's important and desired to be able to exploit the latest
hardware generation, means building code for it, but also maintaining
and potentially debugging it.
Hence, the modifications in binutils/gdb
(which is part of a bigger hwe effort).
Without this no proper z17 code life-cycle management (incl. debugging)
is possible and opcodes might be unknown.
* With the above I believe that this corresponds to a hardware
enablement SRU.
* It introduces support for the new IBM z17 hardware to binutils.
* Some Ubuntu releases (like plucky) have already 'anonymous' support
for in terms of 'arch-15', other Ubuntu releases have no 'arch-15' nor
z17 support at all and require two more patches.
* Without this binutils are not aware about the new z17 hardware generation
and it's opcodes etc.
[ Fix ]
* eeafc61979c6f8399bb5ce770e46a00823a5cfae ("s390: Make operand table
indices relative to each other") - pre-req. for jammy only
* a3f1e7c56a60573562e8578ae8b675ec1f4448e7 ("s390: Simplify
(dis)assembly of insn operands with const bits") - pre-req. for jammy,
noble and oracular
* a98a6fa2d8ef5eb61534b07db80850dcdf07bdb4 ("s390: Add arch15
instructions") - pre-req. for jammy, noble and oracular
* < 981fe5fd80faf511aa265e841a380c9b46be30e6 ("390: Add support for
z17 as CPU name") >
[ Test Plan ]
* Check if the same (proper) opcodes are detected on an IBM z17
system with and without the patch.
Since the identification and name of a z17 system was added.
* Or the simplest test is probably to check
(after having 'binutils' installed on an
Ubuntu Server 25.04, 24.10 or 24.04 s390x system)
if not only:
'as -m64 -march=arch15 --target-help'
but especially also:
'as -m64 -march=z17 --target-help'
succeeds and leads to the same output.
(As it does for '-march=arch14' and '-march=z16'.)
* Due to the lack of hardware this needs to be tested at IBM.
[ Where problems could occur ]
* The request came in to apply only commit eeafc61979c6.
But this commit alone only applies to plucky as-is.
And in case of plucky I think that the risk for regressions is
relatively moderate, since it mainly adds to the opcodes "z17"
in addition to the already existing "arch15".
* Regressions are still possible, for example if the statements are
not properly expanded with ANDs or ||s, but this is testable
and covered by the test plan.
* On top the new name could be wrong, or the name could be accidentally
mapped to the wrong internal arch.
(The test plan above will allow to identify this and the previous bullet.)
* For oracular (which could probably be skipped now, because we are
very close to it's end of live anyway) and for noble, two more
commits are needed. This definitely increases the potential risk of
regressions.
* But add. commits add the actual "arch15" and it's corresponding code,
before then making "arch15" also known as "z17" (1st commit).
* Commit a98a6fa2d8ef only adds code and opcodes,
hence this will ideally not affect any older hw generations.
* Commit a3f1e7c56a60 however introduces a simplification on how
operands are handled with const bits.
But this is already included in oracular and plucky, so it's there
as well as upstream established and tested.
* In addition all this is limited to the s390x architecture
(except the doc file as/doc/as.texi),
and will cause no harm for any other architecture,
and the request for adding these commits is coming from the
architecture owner.
* Anyway, the majority of risk is in this later commit, and it could
be helpful to mitigate this with further test cases.
[ Other Info ]
* binutils maintainer (doko) told me that binutils for questing
will be updated anyway to latest release/snapshot,
so nothing to do for questing in this LP bug (and set to Invalid).
* Due to the proximity of oracular's end of life,
the SRU to oracular might be skipped.
* Due to the growing amount of changes that are needed for jammy
I updated the status to 'Opinion'.
__________
With IBM having announced the new IBM z17, Ubuntu 22.04 and 24.04
should be enabled to run properly on the latest s390x hardware.
While plucky has already the required patches included, please
backport to noble and jammy the GNU Binutils mainline commit
981fe5fd80fa ("s390: Add support for z17 as CPU name"), which adds the
real CPU name "z17" as alternative for "arch15".
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2108997/+subscriptions
More information about the foundations-bugs
mailing list