https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79041
Bug ID: 79041
Summary: aarch64 backend emits R_AARCH64_ADR_PREL_PG_HI21
relocation despite -mpc-relative-literal-loads option
being used
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rschiele at gmail dot com
Target Milestone: ---
Created attachment 40487
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40487&action=edit
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.
