https://sourceware.org/bugzilla/show_bug.cgi?id=22589
--- Comment #2 from Julius Werner <jwerner at chromium dot org> ---
> Actually the offset stored in the instruction *is* zero.
Right, but I think that is incorrect. The point of the 'adrp <reg>, <symbol>'
mnemonic is that you want to generate an instruction that contains the right
PC-relative offset so that when executed at the address it will end up at, the
(absolute) high 20 bits of <symbol> will be written into <reg>. Since the
offset that needs to be put into the instruction is PC-relative, the assembler
generates a relocation and it's the linker's job to fill that in with the right
value when it determines the final address for the instruction.
Consider this counterexample which works correctly:
test2.s:
.global zerofunc
.section .zero
zerofunc:
ret
test1.s:
.section .text
_start:
adrp x0, zerofunc
add x0, x0, :lo12:zerofunc
Which individually assemble into:
Disassembly of section .text:
0000000000000000 <_start> (File Offset: 0x40):
0: 90000000 adrp x0, 0 <zerofunc> (File Offset: 0x40)
0: R_AARCH64_ADR_PREL_PG_HI21 zerofunc
4: 91000000 add x0, x0, #0x0
4: R_AARCH64_ADD_ABS_LO12_NC zerofunc
...and...
Disassembly of section .zero:
0000000000000000 <zerofunc> (File Offset: 0x40):
0: d65f03c0 ret
And then when I link the two together, I get:
Disassembly of section .text:
0000000000400078 <_start> (File Offset: 0x78):
400078: 90ffe000 adrp x0, 0 <zerofunc> (File Offset:
0xffffffffffc00000)
40007c: 91000000 add x0, x0, #0x0
Disassembly of section .zero:
0000000000000000 <zerofunc> (File Offset: 0x80):
0: d65f03c0 ret
As you can see, the linker inserted the right offset into the instruction so
that when applied relative to the PC that the instruction was linked at, the
resulting value in x0 will be 0. Everything in this example is the same as in
the failure case, except that the symbol pointed to by the relocation is a
defined symbol with value 0 rather than an undefined weak symbol. The linker
should treat both of these the same for address calculations, but it doesn't
seem to do so.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
