[lld] r249340 - Create R_X86_64_RELATIVE when needed.

[Rafael Espíndola via llvm-commits]

>> Probably yes (not familiar with TOC). I guess another way of saying
>> it
>> is that these are input relocations that don't require a "full"
>> dynamic relocation. If nothing else requires it, we end up with a
>> getRelativeReloc(). Returning false will force a dynamic relocation
>> to
>> be created.
>
> What does "require" a relocation mean?

Causes one to be added to the dynamic table.


> This might depend on your definition of relative. First, we have relocations like R_PPC64_ADDR32, which are not size_t, and should error if they overflow. If you assume that a shared library might appear anywhere in the 64-bit address space (and not just in the lower 2^32 bytes), then this is indeed dangerous.
>
> But then we have relocations like: R_PPC64_ADDR16_LO, R_PPC64_ADDR16_HA, R_PPC64_ADDR16_HIGHERA and R_PPC64_ADDR16_HIGHESTA, which can be used to piece together an address like this (from the PPC64 ELF v1 ABI spec):
>
>     lis   r3,SYM at highesta
>     ori   r3,SYM at highera
>     sldi  r3,r3,32
>     oris  r3,r3,SYM at ha
>     ld    r4,SYM at l(r3)
>
> each of these represents a part of an absolute address, but each is less than size_t.

But none of the is relative, right?  The first one for example has an
expression of "#lo(S + A)". If there is a relocation with an
expression of "#lo(S + A - P)", than the assumption we currently have
is broken.

Cheers,
Rafael