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

[Peter Smith via llvm-commits]

I'm a bit hesitant to produce an error as who knows what an assembly
language programmer might come up with. A warning might be
appropriate.

I'll go open a bug now.

Peter

On 10 November 2016 at 15:34, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> 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