[Bug 2108997] Comment bridged from LTC Bugzilla

bugproxy 2108997 at bugs.launchpad.net
Wed Mar 4 14:02:11 UTC 2026


------- Comment From JREMUS at de.ibm.com 2026-03-04 08:49 EDT-------
Hello Frank and Vladimir, I have successfully verified both the binutils and gdb packages from noble-proposed:

# apt-cache policy binutils
binutils:
Installed: 2.42-4ubuntu2.10
Candidate: 2.42-4ubuntu2.10
Version table:
*** 2.42-4ubuntu2.10 100
100 http://ports.ubuntu.com/ubuntu-ports noble-proposed/main s390x Packages
100 /var/lib/dpkg/status
2.42-4ubuntu2.8 500
500 http://ports.ubuntu.com/ubuntu-ports noble-updates/main s390x Packages
500 http://ports.ubuntu.com/ubuntu-ports noble-security/main s390x Packages
2.42-4ubuntu2 500
500 http://ports.ubuntu.com/ubuntu-ports noble/main s390x Packages

# man as | grep z17
arch11), z14 (or arch12), z15 (or arch13), z16 (or arch14), or z17 (or arch15).
# echo '.machine "z17"' | as -march=z17
# echo '.machine "arch15"' | as -march=arch15

# apt-cache policy gdb
gdb:
Installed: 15.1-1ubuntu1~24.04.1
Candidate: 15.1-1ubuntu1~24.04.1
Version table:
*** 15.1-1ubuntu1~24.04.1 100
100 http://ports.ubuntu.com/ubuntu-ports noble-proposed/main s390x Packages
100 /var/lib/dpkg/status
15.0.50.20240403-0ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports noble/main s390x Packages

# gdb tmpdir/gdb-zarch-arch15
GNU gdb (Ubuntu 15.1-1ubuntu1~24.04.1) 15.1
...
(gdb) disassemble foo
Dump of assembler code for function foo:
Dump of assembler code for function foo:
0x0000000001000078 <+0>:     vblend  %v15,%v17,%v20,%v24,13
0x000000000100007e <+6>:     vblendb %v15,%v17,%v20,%v24
0x0000000001000084 <+12>:    vblendh %v15,%v17,%v20,%v24
0x000000000100008a <+18>:    vblendf %v15,%v17,%v20,%v24
0x0000000001000090 <+24>:    vblendg %v15,%v17,%v20,%v24
0x0000000001000096 <+30>:    vblendq %v15,%v17,%v20,%v24
0x000000000100009c <+36>:    veval   %v15,%v17,%v20,%v24,253
0x00000000010000a2 <+42>:    vgem    %v15,%v17,13
0x00000000010000a8 <+48>:    vgemb   %v15,%v17
0x00000000010000ae <+54>:    vgemh   %v15,%v17
0x00000000010000b4 <+60>:    vgemf   %v15,%v17
0x00000000010000ba <+66>:    vgemg   %v15,%v17
0x00000000010000c0 <+72>:    vgemq   %v15,%v17
0x00000000010000c6 <+78>:    vuphg   %v15,%v17
0x00000000010000cc <+84>:    vuplhg  %v15,%v17
0x00000000010000d2 <+90>:    vuplg   %v15,%v17
0x00000000010000d8 <+96>:    vupllg  %v15,%v17
0x00000000010000de <+102>:   vavgq   %v15,%v17,%v20
0x00000000010000e4 <+108>:   vavglq  %v15,%v17,%v20
0x00000000010000ea <+114>:   vecq    %v15,%v17
0x00000000010000f0 <+120>:   veclq   %v15,%v17
0x00000000010000f6 <+126>:   vceqq   %v15,%v17,%v20
0x00000000010000fc <+132>:   vceqqs  %v15,%v17,%v20
0x0000000001000102 <+138>:   vchq    %v15,%v17,%v20
0x0000000001000108 <+144>:   vchqs   %v15,%v17,%v20
0x000000000100010e <+150>:   vchlq   %v15,%v17,%v20
0x0000000001000114 <+156>:   vchlqs  %v15,%v17,%v20
0x000000000100011a <+162>:   vclzq   %v15,%v17
0x0000000001000120 <+168>:   vctzq   %v15,%v17
0x0000000001000126 <+174>:   vlcq    %v15,%v17
0x000000000100012c <+180>:   vlpq    %v15,%v17
0x0000000001000132 <+186>:   vmxq    %v15,%v17,%v20
0x0000000001000138 <+192>:   vmxlq   %v15,%v17,%v20
0x000000000100013e <+198>:   vmnq    %v15,%v17,%v20
0x0000000001000144 <+204>:   vmnlq   %v15,%v17,%v20
0x000000000100014a <+210>:   vmalg   %v15,%v17,%v20,%v24
0x0000000001000150 <+216>:   vmalq   %v15,%v17,%v20,%v24
0x0000000001000156 <+222>:   vmahg   %v15,%v17,%v20,%v24
0x000000000100015c <+228>:   vmahq   %v15,%v17,%v20,%v24
0x0000000001000162 <+234>:   vmalhg  %v15,%v17,%v20,%v24
0x0000000001000168 <+240>:   vmalhq  %v15,%v17,%v20,%v24
0x000000000100016e <+246>:   vmaeg   %v15,%v17,%v20,%v24
0x0000000001000174 <+252>:   vmaleg  %v15,%v17,%v20,%v24
0x000000000100017a <+258>:   vmaog   %v15,%v17,%v20,%v24
0x0000000001000180 <+264>:   vmalog  %v15,%v17,%v20,%v24
0x0000000001000186 <+270>:   vmhg    %v15,%v17,%v20
0x000000000100018c <+276>:   vmhq    %v15,%v17,%v20
0x0000000001000192 <+282>:   vmlhg   %v15,%v17,%v20
0x0000000001000198 <+288>:   vmlhq   %v15,%v17,%v20
0x000000000100019e <+294>:   vmlg    %v15,%v17,%v20
0x00000000010001a4 <+300>:   vmlq    %v15,%v17,%v20
0x00000000010001aa <+306>:   vmeg    %v15,%v17,%v20
0x00000000010001b0 <+312>:   vmleg   %v15,%v17,%v20
0x00000000010001b6 <+318>:   vmog    %v15,%v17,%v20
0x00000000010001bc <+324>:   vmlog   %v15,%v17,%v20
0x00000000010001c2 <+330>:   vd      %v15,%v17,%v20,13,12
0x00000000010001c8 <+336>:   vdf     %v15,%v17,%v20,13
0x00000000010001ce <+342>:   vdg     %v15,%v17,%v20,13
0x00000000010001d4 <+348>:   vdq     %v15,%v17,%v20,13
0x00000000010001da <+354>:   vdl     %v15,%v17,%v20,13,12
0x00000000010001e0 <+360>:   vdlf    %v15,%v17,%v20,13
0x00000000010001e6 <+366>:   vdlg    %v15,%v17,%v20,13
0x00000000010001ec <+372>:   vdlq    %v15,%v17,%v20,13
0x00000000010001f2 <+378>:   vr      %v15,%v17,%v20,13,12
0x00000000010001f8 <+384>:   vrf     %v15,%v17,%v20,13
0x00000000010001fe <+390>:   vrg     %v15,%v17,%v20,13
0x0000000001000204 <+396>:   vrq     %v15,%v17,%v20,13
0x000000000100020a <+402>:   vrl     %v15,%v17,%v20,13,12
0x0000000001000210 <+408>:   vrlf    %v15,%v17,%v20,13
0x0000000001000216 <+414>:   vrlg    %v15,%v17,%v20,13
0x000000000100021c <+420>:   vrlq    %v15,%v17,%v20,13
0x0000000001000222 <+426>:   clzg    %r6,%r9
0x0000000001000226 <+430>:   ctzg    %r6,%r9
0x000000000100022a <+434>:   lxab    %r6,-10000(%r9,%r11)
0x0000000001000230 <+440>:   lxah    %r6,-10000(%r9,%r11)
0x0000000001000236 <+446>:   lxaf    %r6,-10000(%r9,%r11)
0x000000000100023c <+452>:   lxag    %r6,-10000(%r9,%r11)
0x0000000001000242 <+458>:   lxaq    %r6,-10000(%r9,%r11)
0x0000000001000248 <+464>:   llxab   %r6,-10000(%r9,%r11)
0x000000000100024e <+470>:   llxah   %r6,-10000(%r9,%r11)
0x0000000001000254 <+476>:   llxaf   %r6,-10000(%r9,%r11)
0x000000000100025a <+482>:   llxag   %r6,-10000(%r9,%r11)
0x0000000001000260 <+488>:   llxaq   %r6,-10000(%r9,%r11)
0x0000000001000266 <+494>:   bextg   %r6,%r9,%r11
0x000000000100026a <+498>:   bdepg   %r6,%r9,%r11
0x000000000100026e <+502>:   kimd    %r6,%r9
0x0000000001000272 <+506>:   kimd    %r6,%r9,13
0x0000000001000276 <+510>:   klmd    %r6,%r9
0x000000000100027a <+514>:   klmd    %r6,%r9,13
0x000000000100027e <+518>:   vcvbq   %v15,%v17,13
0x0000000001000284 <+524>:   vcvdq   %v15,%v17,253,12
0x000000000100028a <+530>:   vtp     %v15
0x0000000001000290 <+536>:   vtp     %v15,65533
0x0000000001000296 <+542>:   vtz     %v15,%v17,65533
0x000000000100029c <+548>:   cal     %r3,10(%r1),20(%r2)
0x00000000010002a2 <+554>:   calg    %r3,10(%r1),20(%r2)
0x00000000010002a8 <+560>:   calgf   %r3,10(%r1),20(%r2)
0x00000000010002ae <+566>:   pfcr    %r1,%r3,-10000(%r2)
End of assembler dump.

-- 
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:
  Fix Released
Status in binutils source package in Jammy:
  Opinion
Status in binutils source package in Noble:
  Fix Committed
Status in gdb source package in Noble:
  Fix Committed
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 and gdb.
     gdb needs to be re-build with the updated binutils to pick up the
     disassember code changes for z17

   * 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. and gdb is unaware of the z17 opcodes.

   * 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") >

   * 0588b2173bf9aeff9eadc0cc024c4c69e69114d ("390: Add arch15
  instruction names")

   * 6445f36a2f9e41b1744d0327e7ec243cb7fac12 ("s390: Add arch15
  Concurrent-Functions Facility insns")

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

   * Since the opcodes are available in plain text files,
     it makes sense to compare them with upstream v2.45 (that
     is known to have full z17 support):
     $ mkdir pkg
     $ apt-src -l ./pkg install binutils
     ...
     $ mkdir upstream
     $ git clone -b binutils-2_45 git://sourceware.org/git/binutils-gdb.git upstream
     ...
     $ diff -u pkg/binutils-2.42/opcodes/s390-opc.txt upstream/binutils-2_45/opcodes/s390-opc.txt

   * One may also compare the opcode based on the source file:
     $ diff -u pkg/binutils-2.42/opcodes/s390-opc.c upstream/binutils-2_45/opcodes/s390-opc.c

   * Use gdb and do a trial disassembly:
     First build the package and testsuite.
     $ mkdir test && cd test
     based on current PPA:
     $ pull-lp-source -D ppa --ppa=ppa:vpa1977/plusone2 binutils
     or later from noble-proposed:
     $ pull-lp-source noble-proposed binutils
     cd binutils-2.42/
     (build using your favorite way)
     $ sudo apt-get install build-essential && sudo apt-get build-dep binutils
     $ dpkg-buildpackage -S -d
     $ dpkg-buildpackage -us -uc 2>&1 | tee ~/build_log.txt
     This will create ~/test/binutils-2.42/builddir-single/gas/testsuite/tmpdir/zarch-arch15.o
     cd ~/test/binutils-2.42/builddir-single/gas/testsuite/tmpdir
     Now use gdb to do the disassembly:
     $ ld -o gdb-zarch-arch15 zarch-arch15.o 
     ld: warning: cannot find entry symbol _start; defaulting to 0000000001000078
     $ gdb tmpdir/gdb-zarch-arch15
     $ gdb gdb-zarch-arch15
     gdb) disassemble foo
     Dump of assembler code for function foo:
        0x0000000001000078 <+0>:	.long	0xe7f14d00
        0x000000000100007c <+4>:	bxle	%r8,%r9,2033(%r14)
        0x0000000001000080 <+8>:	sth	%r0,1929(%r8)
     ...
        0x00000000010002ac <+564>:	lpdr	%f1,%f4
        0x00000000010002ae <+566>:	.long	0xeb1328f0
        0x00000000010002b2 <+570>:	.short	0xfd16
     End of assembler dump.
     (gdb)

   * 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




More information about the foundations-bugs mailing list