This is the mail archive of the
mailing list for the binutils project.
Re: Absolute symbols
- From: Cary Coutant <ccoutant at gmail dot com>
- To: generic-abi at googlegroups dot com, binutils at sourceware dot org
- Date: Wed, 2 May 2012 20:55:11 -0700
- Subject: Re: Absolute symbols
- References: <20120503014320.GF635@bubble.grove.modra.org>
> Take note "the section number is irrelevant".
SHN_ABS isn't a section number. I'll admit this is a weak point in the
ELF spec -- since the section header table in an executable is
optional, there's no real guidance on what to put in the st_shndx
field to mark a non-absolute symbol. In the absence of any sections at
all (not that I've ever seen such an ELF file in practice), I'd go
> 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.
I think this is an existing problem with Gnu ld. Gold sets st_shndx
for these symbols to the section in which they're defined. It doesn't
seem to have caused any compatibility problems. This is a difference
I've noticed between Gnu ld and gold, and I've concluded that gold is
doing the right thing.
> 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
> ? ?relocation."
> 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.
On the contrary, the only interpretation that makes sense to me is
that it will not change because of relocation at link time or at load
time. Absolute symbols, from the days of the earliest linking loaders,
have been used to represent addresses that are outside the address
space of the module (e.g., memory-mapped addresses or kernel gateway
pages). They've even been used to represent true symbolic constants
(e.g., system entry point numbers, sizes, version numbers). There's no
other way to represent a true absolute symbol, while the meaning you
seek is easily represented by giving the symbol a non-negative