[PATCH] D25560: [ELF] Emit relocation for GOT entry even if it is an absolute symbol

Peter Collingbourne via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 27 10:44:08 PDT 2016


Wouldn't it be better to somehow change how linker scripts are interpreted
rather than breaking absolute symbol semantics?

Peter

On Thu, Oct 27, 2016 at 7:44 AM, Eugene Leviant via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> The problem is that such kind of bugs very quickly become "features" :)
> Here is the real use case:
>
> 1) There is an undefined 'MySym' symbol in a shared library, which has GOT
> entry
> 2) You link this shared library using this script:
>
> SECTIONS {
>    /* .... */
>    PROVIDE_HIDDEN(MySym = .);
>    /* ... */
> }
>
> After library is loaded MySym will have incorrect value, because it is
> actually an absolute symbol.
> I think every GOT entry should be relocated, shouldn't it?
>
>
>
> 2016-10-27 17:32 GMT+03:00 Rafael EspĂ­ndola <rafael.espindola at gmail.com>:
> > On 27 October 2016 at 04:42, Eugene Leviant <evgeny.leviant at gmail.com>
> wrote:
> >>> The entry in the got should always contain 42, not 42 + load address,
> no?
> >>
> >> Looks like it shouldn't. Just try running the same test case
> >> (abs-hidden.s) using ld.bfd and ld.gold.
> >> Interesting fact is that ld.bfd emits two relative relocs: one for
> >> .got and one for .text.
> >
> > So, where are you seeing this being an issue? My argument is that it
> > looks like a bug in bfd/gold, no in lld.
> >
> > Gold produces a relocation to set the got entry to 42 + load_address.
> > BFD does the same for the got, but also changes
> >
> > .quad foo
> >
> > to contain 42 + load_address at runtime. That really looks like a bug,
> > if in a single assembly file we have
> >
> >         .quad foo
> >         foo=42
> >
> > both gas and MC produce a file with no relocations and just the value
> > 42. Why should splitting the asm file in two change it?
> >
> > Cheers,
> > Rafael
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>



-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161027/33c46c1a/attachment.html>


More information about the llvm-commits mailing list