https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rearnsha at gcc dot gnu.org,
| |rsandifo at gcc dot gnu.org
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I admit I know next to nothing about aarch64 relocations/typical PIC code etc.
I think usually aarch64 code uses section anchors, but that is clearly not the
case with these .CRC ifn expansions (why it hasn't been lowered to GIMPLE
earlier if hw doesn't have instructions?).
Anyway, in #c11 testcase (-O2 -fpie), I see in the blah function
adrp x20, _GLOBAL_OFFSET_TABLE_
...
ldr x4, [x20, #:gotpage_lo15:crc_table_for_crc_8_polynomial_0x7]
...
ldr x23, [x20, #:gotpage_lo15:crc_table_for_crc_8_polynomial_0x7]
...
ldr x20, [x20,
#:gotpage_lo15:crc_table_for_crc_16_polynomial_0x8005]
where crc_table_for_crc_16_polynomial_0x8005 is 512 byte .rodata table at
offset 0x20 in .rodata in the object file and
crc_table_for_crc_8_polynomial_0x7 is 256 byte .rodata table at offset 0x220 in
.rodata in the object file. Only the first ldr is actually encountered at
runtime.
In the objdump -dr crc6.o output that is
78: 90000014 adrp x20, 0 <_GLOBAL_OFFSET_TABLE_>
78: R_AARCH64_ADR_PREL_PG_HI21 _GLOBAL_OFFSET_TABLE_
...
8c: f9400284 ldr x4, [x20]
8c: R_AARCH64_LD64_GOTPAGE_LO15 .rodata+0x220
...
f4: f9400297 ldr x23, [x20]
f4: R_AARCH64_LD64_GOTPAGE_LO15 .rodata+0x220
...
148: f9400294 ldr x20, [x20]
148: R_AARCH64_LD64_GOTPAGE_LO15 .rodata+0x20
Now in the binary
[14] .rodata PROGBITS 0000000000400888 000888 000330 00 A
0 0 8
56: 0000000000400ab8 256 OBJECT LOCAL DEFAULT 14
crc_table_for_crc_8_polynomial_0x7
57: 00000000004008b8 512 OBJECT LOCAL DEFAULT 14
crc_table_for_crc_8_polynomial_0x8005
400738: f00000f4 adrp x20, 41f000 <__abi_tag+0x1e274>
...
40074c: f947e684 ldr x4, [x20, #4040]
...
4007b4: f947e697 ldr x23, [x20, #4040]
...
400808: f947e694 ldr x20, [x20, #4040]
As you can see, the actual offset is the same in all 3 cases, and at runtime x4
is loaded from 0x41f000+4040 == 0x41ffc8 and
Contents of section .got:
41ffc0 f0fd4100 00000000 98084000 00000000 ..A.......@.....
41ffd0 00000000 00000000 00000000 00000000 ................
41ffe0 00000000 00000000 ........
So, it loads the crc_table_for_crc_8_polynomial_0x8005 address in all cases,
even when it should have 2 separate .got entries.
I get this with binutils 2.43.1 and 2.43.50.
When using -fuse-ld={gold,lld,mold} the binary segfaults instead of aborting.
So, is this a binutils bug, or gcc bug (something wrong with what it emits),
both?
