[PATCH] D26133: [ELF] Allow relative relocations to absolute symbols in PIC

[Peter Collingbourne via llvm-commits]

On Mon, Dec 12, 2016 at 7:12 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

>
> > It's not a limitation, linker script input file is an additional input to
> > the linker which doesn't replace the default linker script. It should
> only
> > contains symbol definitions, INPUT, GROUP and VERSION commands (see
> > https://sourceware.org/binutils/docs/ld/Implicit-
> Linker-Scripts.html#Implicit-Linker-Scripts
> > for
> > more details)
>
> In which case we would need some expression to mean the base. That is
> just not the same as 0 currently (see below).
>
> >
> > That should fail. That .o file has an ABS symbol, no?
> >>
> >
> > No, because SHN_ABS symbol doesn't mean absolute symbol, it's the
> > representation for image-relative symbols in ELF. I checked this with
> > Roland Mcgrath (who also happened to found this bug) and this is verbatim
> > of what he said. I double checked this with Binutils and it's indeed how
> > SHN_ABS is interpreted by ld.bfd and ld.gold.
>
> All that the spec says is
>
> SHN_ABS
>     The symbol has an absolute value that will not change because of
>     relocation.
>
> But as a quick experiment, a single file with just
>
> .global a
> .hidden a
> a = 42
> .quad a
>
> has no relocations at all, with both mc and gas. That means that the
> .quad is always 42. On the other hand, the file has
>
>  000000000000002a     0 NOTYPE  GLOBAL HIDDEN   ABS a
>
> which is contradictory if ABS means image relative. Is that a bug in gas
> and mc?
>
> If we now use two files, one with
>
>         .quad a
>
> and another with
>
>         .global a
>         .hidden a
>         a = 42
>
> gold will produce a file with no relocations. BFD will produce a
> R_X86_64_RELATIVE, but it is the odd one here.
>
> So if SHN_ABS should mean image-relative, we have more than one bug to
> fix (and one spec to clarify).
>

Hi Rafael,

I found some discussion on the binutils bug tracker and mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=14052
https://sourceware.org/ml/binutils/2012-05/msg00023.html

It looks like the conclusion to be drawn is that BFD's behaviour is wrong.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161212/16465381/attachment.html>