Assemblers change certain relocations referencing a local symbol to
reference the section symbol instead. This conversion is disabled for
many conditions (shouldRelocateWithSymbol), e.g. TLS symbol, for most
targets (including AArch32, x86, PowerPC, and RISC-V) GOT-generating
relocations.
However, AArch64 encodes the GOT-generating intent in MCValue::RefKind
instead of MCSymbolRef::Kind (see commit
0999cbd0b9ed8aa893cce10d681dec6d54b200ad (2014)), therefore not affected
by the code case MCSymbolRefExpr::VK_GOT:. As GNU ld and ld.lld
create GOT entries based on the symbol, ignoring addend, the two ldr
instructions will share the same GOT entry, which is not expected:
ldr x1, [x1, :got_lo12:x] // converted to .data+0 ldr x1, [x1, :got_lo12:y] // converted to .data+4 .data // .globl x, y would suppress STT_SECTION conversion x: .zero 4 y: .long 42
This patch changes AArch64 to suppress local symbol to STT_SECTION
conversion for GOT relocations, matching most other targets. x and y
will use different GOT entries, which IMO is the most sensable behavior.
With this change, the ABI decision on https://github.com/ARM-software/abi-aa/issues/217
will only affect relocations explicitly referencing STT_SECTION symbols, e.g.
ldr x1, [x1, :got_lo12:(.data+0)] ldr x1, [x1, :got_lo12:(.data+4)] // I consider this unreasonable uses
IMO all reasonable use cases are unaffected.
Link: https://github.com/llvm/llvm-project/issues/63418
GNU assembler PR: https://sourceware.org/bugzilla/show_bug.cgi?id=30788
In theory this won't catch VK_GOTTPREL which would get used by something like:
Empirically it looks like TLS relocations to local symbols via GOT expressions does not use a section symbol
generates:
Could be worth a test case to make sure it doesn't get broken in the future.