IssueTracker

As part of an investigation to see if LLD could be used in AOSP we found out that if LLD is used to link linker64 then AOSP will fail to boot at a very early stage. I have tracked it down to the way linker64 determines the address it has been loaded at.

I'm reporting this just to highlight the dependency of the method used to determine the address is dependent on an implementation detail that it isn't clear from the documentation or source code. This might help people doing similar investigations in the future.

I will be raising a PR on LLD to see if I can get the behaviour changed to match, potentially under the --[no-]apply-dynamic-relocs  (which was added to ld.gold and ld.bfd to account for https://android-review.googlesource.com/c/platform/bionic/+/176902)

This is done in linker_main.cpp
extern "C" ElfW(Addr) __linker_init(void* raw_args) {
  KernelArgumentBlock args(raw_args);

  // AT_BASE is set to 0 in the case when linker is run by iself
  // so in order to link the linker it needs to calcuate AT_BASE
  // using information at hand. The trick below takes advantage
  // of the fact that the value of linktime_addr before relocations
  // are run is an offset and this can be used to calculate AT_BASE.
  static uintptr_t linktime_addr = reinterpret_cast<uintptr_t>(&linktime_addr);
  ElfW(Addr) linker_addr = reinterpret_cast<uintptr_t>(&linktime_addr) - linktime_addr;

The key part in the comment above is: "The trick below takes advantage of the fact that the value of linktime_addr before relocations are run is an offset and this can be used to calculate AT_BASE".

On AArch64 this property only holds for ld.gold, and not for ld.lld or for older versions of ld.bfd. On AArch64 RELA relocations are used, these have the property that the addend is encoded in the relocation directive, the dynamic loader ignores the value in the place of the relocation. This means that the value linktime_addr must be in the addend of the RELA relocation, the value of linktime_addr in the data section is not used. As the value of linktime_addr is not used in the relocation calculation both ld.lld and ld.bfd do not write the value into the data section. As a result linktime_addr will always be 0 prior to relocation which obviously causes the linker_addr calculation to give an incorrect result.

This effect can be observed on AArch64 with a small example that extracts the code sequence above:
#include <stdint.h>
int _start(void) {
    static uintptr_t linktime_addr = reinterpret_cast<uintptr_t>(&linktime_addr);
  uintptr_t linker_addr = reinterpret_cast<uintptr_t>(&linktime_addr) - linktime_addr;
  return linker_addr;
}

Using an older ld.bfd from binutils 2.25 or earlier:
When compiled and linked --target=aarch64-linux-gnu --shared -fpic with -fuse-ld=bfd -O2 and disassembled with objdump -s -R -t , I get the following:

SYMBOL TABLE:
0000000000011018 l     O .data  0000000000000008              _ZZ6_startvE13linktime_addr

DYNAMIC RELOCATION RECORDS
0000000000011018 R_AARCH64_RELATIVE  *ABS*+0x0000000000011018

Contents of section .data:
 11010 00000000 00000000 00000000 00000000  ................

Note that the relocation addend has the address of _ZZ6_startvE13linktime_addr but the .data entry does not.

The ld.bfd behaviour was changed in https://sourceware.org/ml/binutils/2016-04/msg00407.html (binutils 2.26). The justification was to match ld.bfd on x86-64.

I note that glibc for AArch64 uses the _DYNAMIC symbol that is also written into _GLOBAL_OFFSET_TABLE_[0]. This is a SVr4 convention that might be a possible alternative, however it seems like there is no single convention used on all platforms so I'm hesitant to promote it as a universal solution. Ideally we can find a convention that all the static linkers can support.