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

Simon Atanasyan via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 14 14:22:39 PDT 2016

atanasyan added a comment.

In http://reviews.llvm.org/D21297#457595, @rafael wrote:

> 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.

So you suggest to hide the fact that it is MIPS specific stuff. Ok, I will rename related functions and expressions. Now I use a similar approach for the R_MIPS_GOT_LOCAL expression so it will be rather easy.

> This should allow handling both preemptable and non preemptable

>  symbols uniformly, no?

I'm not sure. We still need to write GOT entries for preemptable and non preemptable symbols to the different parts of the GOT. Probably we can use a single expression type in both cases but check symbol type in more than one place.

> 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.

What will be a section for preemptable symbol comes from DSO?

> > 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?

BFD and Gold handle (Symbol,Addend) pairs for any type of symbols. So they are ready to handle GOT relocations against preemptable symbols and non-zero addends. So your approach covers this case too.

I will try to re-write the patch and send update for review.



More information about the llvm-commits mailing list