Added an SRU Teamplate entry in the description, thanks Bruce for the test.
The changes build fine, all self tests on build are good [1]. The dep8 sniff tests have just started at [2] and will later be available there. The changes are rather small as seen on [3] But while all that shall help by being good preparation I have no experience on binutils. Therefore I'd now assign to doko so that he can ack&sponsor or comment why this won't be able to happen. [1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4105/+packages [2]: https://bileto.ubuntu.com/#/ticket/4105 [3]: https://code.launchpad.net/~paelzer/ubuntu/+source/binutils/+git/binutils/+merge/386073 ** Description changed: + [Impact] + + * 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. + + Working: + $ 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 + Failing: + $ 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 + + + + --- + + Hi, DPDK has run into some issues in the past - https://bugs.dpdk.org/show_bug.cgi?id=97 - https://bugs.dpdk.org/show_bug.cgi?id=249 + https://bugs.dpdk.org/show_bug.cgi?id=97 + https://bugs.dpdk.org/show_bug.cgi?id=249 Eventually the issues got resolved in binutils via - https://sourceware.org/bugzilla/show_bug.cgi?id=23465 + https://sourceware.org/bugzilla/show_bug.cgi?id=23465 After binutils is fixed people rebuilding DPDK themselve can use - http://patches.dpdk.org/patch/71679/ + http://patches.dpdk.org/patch/71679/ 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. ** Changed in: binutils (Ubuntu Bionic) Assignee: (unassigned) => Matthias Klose (doko) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1883880 Title: 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: New Bug description: [Impact] * 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. Working: $ 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 Failing: $ 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 --- Hi, DPDK has run into some issues in the past https://bugs.dpdk.org/show_bug.cgi?id=97 https://bugs.dpdk.org/show_bug.cgi?id=249 Eventually the issues got resolved in binutils via https://sourceware.org/bugzilla/show_bug.cgi?id=23465 After binutils is fixed people rebuilding DPDK themselve can use http://patches.dpdk.org/patch/71679/ 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: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions -- 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
