[PATCH] D21297: [ELF][MIPS] Support GOT entries for non-preemptible symbols with different addends

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 14 08:45:53 PDT 2016


> In general all MIPS GOT related relocations against (S+A) expect that corresponding GOT entry contain a real address of S + A. For example, here is a quote from R_MIPS_GOT_DISP relocation result description:
>
>   The offset into the global offset table at which the address of the relocation entry symbol, adjusted by the addend, resides during execution.
>
> In fact compilers/assemblers generate GOT related relocations for non-preemptible symbols because in that case they know what happens at the S+A address. I do not know why does compiler require allocation of additional GOT entry instead of adding addend to the result of GOT entry reading. Maybe the idea is to escape additional instructions.

It sounds like we should have another expression. Say
R_GOT_ADDEND_OFF. With that it would be easier to write code that

* Creates a got entry for S+A instead of just S. If the addend is 0,
it uses the existing GotIndex/GotPltIndex. Otherwise we need a map. I
would suggest starting with just a (sym, addend). We can try
optimizing it afterwards.

* When handling the expression,  we would have

case R_GOT_ADDEND_OFFSET:
  return Body.getGotOffset<ELFT>(A);

And the implementation of getGotOffset uses the hash table in the Got
section if the addend is not 0.

This should allow handling both preemptable and non preemptable
symbols uniformly, no?

It also looks like this code would be cleaner if we used
section+offsets instead of symbols is the Relocation vector. I will
give that a try.

> On my test base I have never seen a GOT relocation against preemptible symbol with addend, but I am going to add `fatal` call to catch such case.

What does gold/bfd do in that case?

Cheers,
Rafael


More information about the llvm-commits mailing list