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

Rafael Avila de Espindola via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 12 19:12:02 PST 2016


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

Cheers,
Rafael


More information about the llvm-commits mailing list