[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