[Bug 2108997] Re: [SRU] GDB: Internal binutils code requires updates made for IBM z17 in binutils already

Mon Feb 2 09:03:13 UTC 2026

Hi Frank, Jen,

I have attempted to add prerequisite commits to the list provided in the comment above [1]. 
Would it be possible to confirm that the list below is the one that we want to apply:

561b8d48f s390: Lower severity of assembler syntax errors from fatal to error
f6cd3c4a8 s390: Enhance handling of syntax errors in assembler
11fe57be7 s390: Do not erroneously use base operand value for length operand
398065c7d s390: Correct setting of highgprs flag in ELF output
c7fc47b27 s390: Add comments to assembler operand parsing logic
539328f9c s390: Add test cases for base/index register 0
bf1df8b98 s390: Add test case for disassembler option warn-areg-zero
15f367eea s390: Revise s390-specific assembler option descriptions
a052bc7aa s390: Warn when register name type does not match operand
441a10e14 s390: Print base register 0 as "0" in disassembly
fce30bb8b s390: Allow to explicitly omit base register operand in assembly
72ab3f885 s390: Provide operand number in assembler warning and error messages
c81f07c05 s390: Be more verbose about missing operand type
e6c40194d s390: Document syntax to omit base register operand
e64fa3d04 s390: Simplify (dis)assembly of insn operands with const bits
e3dbbe971 s390: Add arch15 instructions
78305ecc8 s390: Add arch15 instruction names
c5ab651fe s390: Add arch15 Concurrent-Functions Facility insns
d3110d9cc s390: Fix disassembly of optional addressing operands
089a164a6 s390: Treat addressing operand sequence as one in assembler
cf6190f84 s390: Treat addressing operand sequence as one in disassembler
a3ce50326 s390: Simplify parsing of omitted index register operand
146ab6ba4 s390: Additional tests for omitted base register operands
b24c12bc9 s390: Do not omit vector index register 0 in disassembly
5d19f6e77 s390: Do not warn about vector index register 0 in assembly
2635bf9c7 s390: Error if vector index register omitted in assembly
3763d3c4c s390: Add support for z17 as CPU name

Best Regards, 
 Vladimir.

[1] https://bugs.launchpad.net/ubuntu-z-systems/+bug/2108997/comments/47

-- 
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:
  [SRU] 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 gdb package in Ubuntu:
  New
Status in binutils source package in Jammy:
  Opinion
Status in binutils source package in Noble:
  In Progress
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.

   * The intention here is NOT to recompile existing Ubuntu packages
     for a new hardware generation (new base-line) as part of this SRU.
     It is to enable users to compile their own code and applications
     (and debug and maintain it) for and on this new hardware generation.
     Being able to exploit this new hardware generation can have
     a significant positive performance impact for certain use cases.

  [ 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.

   * For regression testing:
     - doing a (PPA) build (e.g. of the s390-tools package)
       on z13 and z15 (that we have direct access to),
       using the new binutils version
     - verifying and comparing the ddeb packages
     - performing a test debug session, verifying that debugging still works

  [ 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