[lld] r286353 - [ELF] ARM and AArch64 undefined weak reference values

[Rafael Espíndola via llvm-commits]

On 10 November 2016 at 10:27, Peter Smith <peter.smith at linaro.org> wrote:
> Hello,
>
> I've had a chance to check over R_AARCH64_ADR_PREL_PG_HI21 to weak
> references. From what I can tell no code-generator should ever use
> that relocation to a weak reference as I don't think that there is any
> sensible value that a linker can return that will work in all cases.
>
> Testing out what gcc and llvm actually do, I see that with non
> position-independent code:
> - gcc uses R_AARCH64_ADR_PREL_PG_HI21 + R_AARCH64_LDST64_ABS_LO12_NC
> to a local literal pool that has a R_AARCH64_ABS64 relocation to the
> weak reference.
> - llvm uses R_AARCH64_ADR_GOT_PAGE and R_AARCH64_LD64_GOT_LO12_NC to a
> linker generated GOT entry.
>
> These approaches avoid a R_AARCH64_ADR_PREL_PG_HI21 relocation to the
> weak reference so I don't think that anything needs changing in llvm.

Should we produce an error in lld if that does show up?

> One small difference between ld.bfd and lld is that lld hard codes the
> GOT location to 0 if the weak reference isn't defined at static link
> time, whereas ld.bfd puts the weak reference into the dynamic symbol
> table with a R_AARCH64_GLOB_DAT relocation. The only thing I can see
> that could realistically exploit this behaviour would be if a program
> dlopens a shared library before lazy symbol resolution of the weak
> reference.

or LD_PRELOAD?

I wouldn't be opposed to having the dynamic relocation. I think we
just handle undefined weak as non-preemptable. We could revisit that.
Could you please open a bug?

Thanks,
Rafael