On first check by the SRU team I got:
[18:34] <sil2100> cpaelzer: ok, looking at the binutils SRU, so you talked to 
do_ko about it, right? Was he +1 on the change?

He was in a private IRC, I now asked him to state it here as well so
that it is visible to the SRU team. And he already did so - thanks!

[18:35] <sil2100> cpaelzer: also, since this is a toolchain package, we
need to first build it in a -security only PPA, as we need it to go to
both -updates and -security

Hmm, I didn't know that is a common pre-check for toolchain packages - thanks 
for the hint.
I have opened a security only all-bionic-arch enabled PPA for this and started 
a build at:
=> https://launchpad.net/~paelzer/+archive/ubuntu/lp-1883880-binutils-sec-only
The first few builds are completed by now.

I hope this helps to remove the remaining blockers to get this into

You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.

  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  In Progress

Bug description:

   * the assembler scales non 8 bit cases which was identified
     to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
     time error. Instead the instructions might silently be corrupted until 
     running. Things might even work on some but fail on other systems if 
     e.g. the AVX code paths only run on newer chips.

    * The fix is upstream for a while and not re-changed again. Furthermore 
      it is in several Ubuntu releases without bugs due to that, which should 
      make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
     0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
     0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
     small change and only affects something formerly clearly broken. So it 
     should be good and only change cases formerly being bad.
     But OTOH binutils areused in so many cases that I feel unable to say
     "nothing will happen". The change goes to the gnu assembler, so that is 
     the place to look out for regressions.

  [Other Info]
   * needs a sponsor experienced with binutils to check potential pitfalls


  DPDK has run into some issues in the past

  Eventually the issues got resolved in binutils via

  After binutils is fixed people rebuilding DPDK themselve can use
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:

Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to