[PATCH] D51030: [AArch64] Optimise load(adr address) to ldr address

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

In https://reviews.llvm.org/D51030#1207898, @dmgreen wrote:

> In https://reviews.llvm.org/D51030#1207378, @peter.smith wrote:
>
> > - I can't see anything obviously wrong with the BFD code for handling LO19
>
>
> Trying a newer ld.bfd (2.31 from today) this is working fine in both modes, so perhaps the issue is old. It was 2.27/2.28 that I was trying earlier, but the program being compiled (timeit-target) is small enough that I didn't //expect// it to go out of range.


I can reproduce with the installed binutils on Ubuntu 16.04 (2.26.1). Taking a look at the object that causes the problem the specific error message I see is

  get.dir/timeit.c.o  -o timeit-target 
  /usr/bin/ld: CMakeFiles/timeit-target.dir/timeit.c.o(.text+0x5dc): unresolvable R_AARCH64_LD_PREL_LO19 relocation against symbol `stderr@@GLIBC_2.17'

I think that this is likely to be the only time in the test suite that there is a R_AARCH64_LD_PREL_LO19 to a data symbol in a shared library. In theory this should generate a R_AARCH64_COPY dynamic relocation. I think that this was fixed as part of the changes made in https://sourceware.org/bugzilla/show_bug.cgi?id=21532 "[AArch64] Allow COPY relocation elimination" as prior to that R_AARCH64_LD_PREL_LO19 wasn't in the switch statement to generate copy relocations. The change made it into binutils 2.29.

>> If there is anything I can do to help here let me know?
> 
> I think the tls problems was me getting the code to add R_AARCH64_GOT_LD_PREL19 and R_AARCH64_TLSIE_LD_GOTTPREL_PREL19 relocations incorrect. GOT seems easy enough now I've figured out what was wrong, TLSIE I'm not sure about yet but I'm guessing it should be possible.

I'm guessing that this is the relaxation from TLSIE to TLSLE? I think that will be possible as it should be possible to tell from the relocation at the place which code model is being used.


https://reviews.llvm.org/D51030