Home Original page

glibc use of EI_ABIVERSION

Alan Modra amodra@gmail.com
Tue Oct 8 01:17:00 GMT 2013 
Hi,
There seems to be some code in glibc that makes use of EI_ABIVERSION
on Linux targets.  See libc-abis.  However, the linker does not
set EI_ABIVERSION so none of this code is effective.

Is glibc going anywhere with a plan to use EI_ABIVERSION?  If so, it
seems to have stagnated since early 2010..

More importantly, is using EI_ABIVERSION to signal the presence of
unique or ifunc symbols a correct usage of EI_ABIVERSION?  I'm
inclined to think not.  (The reason I've been looking into the intent
of EI_ABIVERSION is that I was thinking of using the field to identify
the new ppc64 ABI we've been cobbling together, and have come to the
conclusion that usage would be incorrect too.)

To see why, it's necessary to first look at EI_OSABI, another field
that has caused controversy in the past.  Cary had this to say in
http://www.sourceware.org/ml/binutils/2000-11/msg00383.html

"There are a number of fields in the ELF format for which ranges of
values or a set of flag bits are reserved for vendor-specific use
(e.g., SHT_LOOS through SHT_HIOS for vendor-specific section types,
and SHF_MASKOS for vendor-specific section attributes).  If an object
file uses any of these values or flag bits, the consumer of the file
must consult the EI_OSABI field to determine what those values or
flags mean."

OS_ABI then is not intended to say anything about the function calling
conventions, OS syscalls, or other features of a particular
processor's ABI and OS.  Its purpose is to enable proper decoding of
ELF fields in object files.  I believe that EI_ABIVERSION has a
similar purpose.  When the gABI says "This field is used to
distinguish among incompatible versions of an ABI." it means
incompatible in the usage of ELF fields in object files.

Merely adding a feature does not warrant bumping EI_ABIVERSION.  As an
obvious example, adding a new relocation type should not change
EI_ABIVERSION.  By the same token, defining STB_GNU_UNIQUE in the
STB_LOOS range doesn't require an EI_ABIVERSION change.  There is no
ambiguity when seeing an ELF_ST_BIND value of 10 on ELFOSABI_LINUX.
It means STB_GNU_UNIQUE whether or not your version of ld.so can
handle those symbols correctly..

An example of a legitimate use of EI_ABIVERSION would be if the MIPS
people, who have already used most available bits in st_other, decided
they needed to re-purpose some bits.  Redefining some or all of the
st_other bits could be done with a increment of the EI_ABIVERSION
field.  This might also be necessary if the gABI defined more st_other
bits, incompatible with current MIPS usage.  EI_ABIVERSION allows
exactly this sort of backwards incompatible change, and using
EI_ABIVERSION for other purposes makes legitimate use more difficult.

-- 
Alan Modra
Australia Development Lab, IBM
More information about the Binutils mailing list