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

[Rui Ueyama via llvm-commits]

On Tue, Jun 14, 2016 at 2:22 PM, Simon Atanasyan <simon at atanasyan.com>
wrote:

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

I'd name it R_MIPS_GOT_ADDEND_OFFSET or something like this as it's
actually MIPS-specific. This should help readers who are not familiar (and
not interested in) MIPS.


> > 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.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D21297
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160614/1264bd48/attachment.html>