[lld] r263228 - Simplify now that local symbols can use getVA.

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 22 14:35:07 PDT 2016

On 22 March 2016 at 17:21, Simon Atanasyan <simon at atanasyan.com> wrote:
> On Tue, Mar 22, 2016 at 6:36 PM, Rafael EspĂ­ndola
> <rafael.espindola at gmail.com> wrote:
>>> For "true" local symbols which can be referenced from the same module
>>> only compiler creates two instructions for address loading:
>>> lw   $8, 0($gp) # R_MIPS_GOT16
>>> addi $8, $8, 0  # R_MIPS_LO16
>>> The first instruction loads high 16 bits of the symbol address while
>>> the second adds an offset. That allows to reduce number of required
>>> GOT entries because only one global offset table entry is necessary
>>> for every 64 KBytes of local data.
>>> Hidden global symbols can be referenced from other object files. And
>>> compiler might do not know that the symbol is hidden. So the compiler
>>> creates a single instruction to load the symbol address and expect
>>> that the corresponding GOT entry holds complete address of the symbol.
>> I see. Could you add that as a comment?
> Sure. But I do not know what is the best place for it. What about
> `GotSection::addEntry`?

Sounds reasonable.

> Compiler considers any global symbol uniformly and generates single
> R_MIPS_GOT16 relocation for address loading. It might generate two
> instructions and two corresponding relocations if it knows that the
> symbols is hidden. And it will work even if the same symbol is
> referenced from another object file. But this approach is not used by
> unknown (to me) reason. Maybe the idea was to have the only GOT entry
> related to the symbol. It is either GOT entry with "page" address or
> GOT entry with "full" address.

OK. It does make the linker life easier. Please mention that too.

Thanks a lot. The ABI is still odd, but at least the comments let
others know it is not magic.


More information about the llvm-commits mailing list