Launchpad has imported 18 comments from the remote bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79041.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2017-01-10T11:17:05+00:00 Robert Schiele wrote: Created attachment 40487 test case to reproduce the problem To support older Cortex A53 CPUs that suffer from erratum 843419 the Linux kernel has some option not to allow certain relocations in kernel modules. To achieve that it utilizes the options -mcmodel=large -mpc- relative-literal-loads. Unfortunately we found a case where gcc does still produce such relocations despite the options being used if optimization level is at least -O2. The code in question is attached and the problem can be reproduced like this: $ aarch64-linux-gnu-gcc -O2 -mcmodel=large -mpc-relative-literal-loads -c t.c $ aarch64-linux-gnu-objdump -r t.o t.o: file format elf64-littleaarch64 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000000000018 R_AARCH64_CALL26 strcmp 0000000000000030 R_AARCH64_ADR_PREL_PG_HI21 .text+0x0000000000000060 0000000000000034 R_AARCH64_ADD_ABS_LO12_NC .text+0x0000000000000060 0000000000000050 R_AARCH64_ABS64 .rodata.str1.8 Obviously the attached code by itself might not be very useful but it is a stripped-down code example of a real-world kernel driver just to demonstrate the problem. Some observations: 1. The problem did reproduce with the latest patches from Linaro and with the upstream version (without the Linaro patches) of latest gcc 6 branch. 2. The problem did also reproduce with the gcc 5 branch including the Linaro patches on that branch. I did not check the gcc 5 branch without the Linaro patches. 3. The problem disappears if the useless (not used in the code) second entry in the array gets removed from the code. 4. The problem seems to be in the code that is generated for the strcpy by the compiler. 5. The problem disappears if the string is made longer. In that case the string ends up in .rodata.str1.8 section like the other string, while in the problematic case it is stored as .xword type in .text section. So my personal conclusion is that some code in the backend involved in this strcpy optimization does not honor the -mpc-relative-literal-loads option properly. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/0 ------------------------------------------------------------------------ On 2017-01-10T11:36:04+00:00 Ktkachov wrote: Confirmed on GCC 6.3.1 This doesn't appear on trunk. Trunk generates a pc-relative load. aarch64-none-elf-objdump -r t.o reloc.o: file format elf64-littleaarch64 RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000000000018 R_AARCH64_CALL26 strcmp 0000000000000038 R_AARCH64_ABS64 .rodata.str1.8 0000000000000040 R_AARCH64_ABS64 .rodata.str1.8+0x0000000000000008 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/1 ------------------------------------------------------------------------ On 2017-01-10T16:22:55+00:00 Ktkachov wrote: This was fixed by a trunk patch that has been only partially backported to GCC 6. Testing a patch to fix it. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/2 ------------------------------------------------------------------------ On 2017-01-11T06:25:55+00:00 Robert Schiele wrote: If you point me to the specific patch that you have in mind I can in parallel already test whether besides the test case I provided it also fixes the original problem this was detected with. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/3 ------------------------------------------------------------------------ On 2017-01-11T16:34:07+00:00 Ktkachov wrote: (In reply to Robert Schiele from comment #3) > If you point me to the specific patch that you have in mind I can in > parallel already test whether besides the test case I provided it also fixes > the original problem this was detected with. I've posted a patch for review at: https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00736.html It should apply to a GCC 6-based tree (but not GCC 7 trunk which doesn't exhibit this bug) Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/4 ------------------------------------------------------------------------ On 2017-01-12T07:39:19+00:00 Robert Schiele wrote: Thanks! I can confirm that this also fixes the original problem for all cases we observed so far. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/5 ------------------------------------------------------------------------ On 2017-01-12T17:42:22+00:00 Ktkachov wrote: thanks for testing this out Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/6 ------------------------------------------------------------------------ On 2017-07-24T18:07:10+00:00 Wilco-z wrote: Author: wilco Date: Mon Jul 24 18:06:37 2017 New Revision: 250478 URL: https://gcc.gnu.org/viewcvs?rev=250478&root=gcc&view=rev Log: Fix PR79041 As described in PR79041, -mcmodel=large -mpc-relative-literal-loads may be used to avoid generating ADRP/ADD or ADRP/LDR. However both trunk and GCC7 may still emit ADRP for some constant pool literals. Fix this by adding a aarch64_pcrelative_literal_loads check. gcc/ PR target/79041 * config/aarch64/aarch64.c (aarch64_classify_symbol): Avoid SYMBOL_SMALL_ABSOLUTE for literals with pc-relative literals gcc/testsuite/ * gcc.target/aarch64/pr79041-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr79041-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/16 ------------------------------------------------------------------------ On 2017-07-25T12:09:31+00:00 Wilco-z wrote: Author: wilco Date: Tue Jul 25 12:08:59 2017 New Revision: 250514 URL: https://gcc.gnu.org/viewcvs?rev=250514&root=gcc&view=rev Log: Fix PR79041 As described in PR79041, -mcmodel=large -mpc-relative-literal-loads may be used to avoid generating ADRP/ADD or ADRP/LDR. However both trunk and GCC7 may still emit ADRP for some constant pool literals. Fix this by adding a aarch64_pcrelative_literal_loads check. gcc/ PR target/79041 * config/aarch64/aarch64.c (aarch64_classify_symbol): Avoid SYMBOL_SMALL_ABSOLUTE for literals with pc-relative literals. gcc/testsuite/ * gcc.target/aarch64/pr79041-2.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/aarch64/pr79041-2.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/aarch64/aarch64.c branches/gcc-7-branch/gcc/testsuite/ChangeLog Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/17 ------------------------------------------------------------------------ On 2017-07-25T13:14:04+00:00 Wilco-z wrote: Fixed in GCC7 and trunk. GCC6 requires https://gcc.gnu.org/ml/gcc- patches/2017-06/msg01708.html. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/18 ------------------------------------------------------------------------ On 2017-07-26T11:55:35+00:00 Wilco-z wrote: Author: wilco Date: Wed Jul 26 11:55:03 2017 New Revision: 250567 URL: https://gcc.gnu.org/viewcvs?rev=250567&root=gcc&view=rev Log: Disable pr79041-2.c with -mabi=ilp32. gcc/testsuite/ PR target/79041 * gcc.target/aarch64/pr79041-2.c: Don't run in ILP32. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/pr79041-2.c Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/19 ------------------------------------------------------------------------ On 2017-07-26T11:58:30+00:00 Wilco-z wrote: Author: wilco Date: Wed Jul 26 11:57:57 2017 New Revision: 250569 URL: https://gcc.gnu.org/viewcvs?rev=250569&root=gcc&view=rev Log: Disable pr79041-2.c with -mabi=ilp32. gcc/testsuite/ PR target/79041 * gcc.target/aarch64/pr79041-2.c: Don't run in ILP32. Modified: branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.target/aarch64/pr79041-2.c Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/20 ------------------------------------------------------------------------ On 2017-09-24T22:44:35+00:00 Pinskia wrote: This test also fails with -fpic. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/27 ------------------------------------------------------------------------ On 2017-09-25T10:52:22+00:00 Wilco-z wrote: (In reply to Andrew Pinski from comment #12) > This test also fails with -fpic. It doesn't run in the testsuite with -fpic, so is it a problem? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/28 ------------------------------------------------------------------------ On 2017-09-25T22:04:09+00:00 Pinskia wrote: (In reply to Wilco from comment #13) > It doesn't run in the testsuite with -fpic, so is it a problem? I run the testsuite with RUNTESTFLAGS='--target_board=unix/\{,-fpic\}' and this testcase fails in the -fpic is selected. Note this is done as we don't have enough coverage for -fpic code in the normal testsuite run; running the testsuite this way has allowed me to file PIC related bugs in the past. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/29 ------------------------------------------------------------------------ On 2018-01-17T16:32:13+00:00 Wilco-z wrote: Author: wilco Date: Wed Jan 17 16:31:42 2018 New Revision: 256800 URL: https://gcc.gnu.org/viewcvs?rev=256800&root=gcc&view=rev Log: [AArch64] PR82964: Fix 128-bit immediate ICEs This fixes PR82964 which reports ICEs for some CONST_WIDE_INT immediates. It turns out decimal floating point CONST_DOUBLE get changed into CONST_WIDE_INT without checking the constraint on the operand, which results in failures. Avoid this by only allowing SF/DF/TF mode floating point constants in aarch64_legitimate_constant_p. A similar issue can occur with 128-bit immediates which may be emitted even when disallowed in aarch64_legitimate_constant_p, and the constraints in movti_aarch64 don't match. Fix this with a new constraint and allowing valid immediates in aarch64_legitimate_constant_p. Rather than allowing all 128-bit immediates and expanding in up to 8 MOV/MOVK instructions, limit them to 4 instructions and use a literal load for other cases. Improve a few TImode tests to use a literal and ensure they are skipped with -fpic. This fixes all reported failures. gcc/ PR target/82964 * config/aarch64/aarch64.md (movti_aarch64): Use Uti constraint. * config/aarch64/aarch64.c (aarch64_mov128_immediate): New function. (aarch64_legitimate_constant_p): Just support CONST_DOUBLE SF/DF/TF mode to avoid creating illegal CONST_WIDE_INT immediates. * config/aarch64/aarch64-protos.h (aarch64_mov128_immediate): Add declaration. * config/aarch64/constraints.md (aarch64_movti_operand): Limit immediates. * config/aarch64/predicates.md (Uti): Add new constraint. gcc/testsuite/ PR target/79041 PR target/82964 * gcc.target/aarch64/pr79041-2.c: Improve test, disable with fpic. * gcc.target/aarch64/pr78733.c: Improve test, disable with fpic. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-protos.h trunk/gcc/config/aarch64/aarch64.c trunk/gcc/config/aarch64/aarch64.md trunk/gcc/config/aarch64/constraints.md trunk/gcc/config/aarch64/predicates.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/pr78733.c trunk/gcc/testsuite/gcc.target/aarch64/pr79041-2.c Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/33 ------------------------------------------------------------------------ On 2018-11-19T14:45:59+00:00 Marxin-m wrote: Wilco: Can the bug be marked as resolved? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/34 ------------------------------------------------------------------------ On 2018-11-19T15:16:52+00:00 Wilco-z wrote: (In reply to Martin Liška from comment #16) > Wilco: Can the bug be marked as resolved? Yes it is fixed on all active branches. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1695093/comments/35 ** Changed in: linux Status: In Progress => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1695093 Title: arm64: "unsupported RELA relocation: 275" loading certain modules Status in Linux: Fix Released Status in gcc-5 package in Ubuntu: Fix Released Status in gcc-6 package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in gcc-5 source package in Xenial: Fix Released Status in gcc-6 source package in Xenial: Invalid Status in linux source package in Xenial: Fix Released Status in gcc-5 source package in Yakkety: Won't Fix Status in gcc-6 source package in Yakkety: Won't Fix Status in linux source package in Yakkety: Won't Fix Status in gcc-5 source package in Zesty: Won't Fix Status in gcc-6 source package in Zesty: Won't Fix Status in linux source package in Zesty: Won't Fix Bug description: [Impact] Certain kernel modules are unloadable (libceph & scsi_debug) due to the compiler generating unsupported relocations. This symptom is similar to LP: #1533009 but, in that case it impacted all modules, and the fix for that appears to remain in place. [Test Case] With the hwe-z kernel: ubuntu@grotian:~$ sudo modprobe libceph modprobe: ERROR: could not insert 'libceph': Exec format error ubuntu@grotian:~$ dmesg [66988.470307] module libceph: unsupported RELA relocation: 275 [Regression Risk] The scope of the fix is restricted to aarch64, so regressions should only impact the arm64 port of Ubuntu. Regressions could impact when literal loads are used - which may have performance impacts or possibly cause software to fail to build/run where it previously did. This is somewhat mitigated by the fact that this has been fixed in artful gcc-5/gcc-6 and used on our buildds for some time. Only "somewhat", because gcc-7 is now the default. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1695093/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
