This is the mail archive of the
mailing list for the binutils project.
- From: Alan Modra <amodra at gmail dot com>
- To: binutils at sourceware dot org, generic-abi at googlegroups dot com
- Date: Thu, 3 May 2012 11:13:20 +0930
- Subject: Absolute symbols
I started of writing the following as a comment in binutils PR14502,
then decided it may be worth airing this to a wider audience.
Absolute symbols in an executable or shared library should be treated
no differently to any other symbol. If a binary is relocated by a
given amount, so should all symbols defined by the binary. The ELF
spec says of symbol values:
"In executable and shared object files, st_value holds a virtual
address. To make these files' symbols more useful for the dynamic
linker, the section offset (file interpretation) gives way to a
virtual address (memory interpretation) for which the section number
Take note "the section number is irrelevant". That's why I say that
an absolute symbol (so designated by having a section number of
SHN_ABS) should be treated no differently to any other symbol in an
executable. If grub or any other kernel relocation code treats
SHN_ABS symbols specially then that is a bug in the loader.
Another data point backing up this interpretation of the ELF
specification is the behaviour of glibc ld.so, which treats a SHN_ABS
symbol just like any other symbol. In fact, this is a necessary
behaviour since certain symbols, eg. _GLOBAL_OFFSET_TABLE_ and
_DYNAMIC, are made SHN_ABS by GNU ld to be compatible with old linkers
on other systems. The value of _GLOBAL_OFFSET_TABLE_ and _DYNAMIC
must relocate in step with the executable or shared library, otherwise
your program won't operate properly.
This of course is in sharp disagreement with another sentence in the
ELF spec that says:
The symbol has an absolute value that will not change because of
I believe the "relocation" referred to here is that performed by the
linker on relocatable object files, *not* relocation of executables
and shared libraries performed by a program loader. That seems to be
the only interpretation that makes the ELF spec self-consistent. In
any case, actual practice trumps the specification.
Australia Development Lab, IBM