Re: EI_ABIVERSION usage

["David O'Brien" <obrien at FreeBSD dot org>]

> Can we please come up with a clear policy on this issue

Since this topic is touchy, let me first ask the most important question
WRT Binutils.  Is there today, or is there planned to be functionality
such that the value of EI_OSABI and EI_ABIVERSION will cause a problem?


On Tue, May 07, 2002 at 04:22:59PM -0700, Jason R Thorpe wrote:
> Not too long ago, Richard Earnshaw and I were scolded *on this list*
> for wanting to set the OSABI field to ELFOSABI_NETBSD for arm-*-netbsdelf*

Not by me.

> The argument was made to us that the OSABI field is not to indicate the
> ABI in the "calling convention" sense, etc. but rather indicates the meanings
> of the various other fields in the ELF program, section, etc. headers, the
> relocation types, etc..

The problem is the spec does not justify that argument.  The spec says
exactly:

    "EI_OSABI" is for "Operating system/ABI identification".
    Byte e_ident[EI_OSABI] identifies the operating system and ABI to
    which the object is targeted.  Some fields in other ELF structures
    have flags and values that have platform specific meanings; the
    interpretation of those fields is determined by the value of this
    byte.

    EI_ABIVERSION 
    Byte e_ident[EI_ABIVERSION] identifies the version of the ABI to
    which the object is targeted. This field is used to distinguish among
    incompatible versions of an ABI. The interpretation of this version
    number is dependent on the ABI identified by the EI_OSABI field.

http://www.caldera.com/developers/gabi/2000-07-17/ch4.eheader.html
(System V Application Binary Interface Edition 4.1)
This was added May 3, 1999.

Note at http://www.caldera.com/developers/gabi/ it says:

    There is more than one instance of these chapters to permit
    references to older instances to remain valid. All modifications to
    these chapters are forward-compatible, so that correct use of an
    older specification will not be invalidated by a newer instance.

On 24 April 2001 it was changed to read:

    EI_OSABI 
    Byte e_ident[EI_OSABI] identifies the OS- or ABI-specific ELF
    extensions used by this file. Some fields in other ELF structures
    have flags and values that have operating system and/or ABI specific
    meanings; the interpretation of those fields is determined by the
    value of this byte. If the object file does not use any extensions,
    it is recommended that this byte be set to 0.

The problem is there is no detailed definition of ABI, and things are
"recommended" and "operating system specific meanings".  Also the group
writing the next spec is (1) closed, (2) aren't the owners of SVR4, (3)
members are highly weighted to a single affiliation.  So I question what
newer gABI specs really mean.

I fail to see line and verse where FreeBSD's (or Richard's proposed) use
of OSABI is wrong.  I have seen where people that later invented their
own way to the problem have pushed hard to try to make FreeBSD's use
"illegal", but they really cannot back it up with the spec IMHO.

BTW, FreeBSD's usage predates 24 April 2001, and is this OK'ed by the
grandfather clause above.

Cary Coutant <cary@cup.hp.com> (the original author of the proposal to add
the EI_OSABI field) wrote a commentary about EI_OSABI as
http://sources.redhat.com/ml/binutils/2000-11/msg00383.html.

    The intent is that any ABI-conforming implementation will be able to
    execute an ABI-conforming binary, even if it uses certain
    vendor-specific features. In many cases, those vendor-specific
    features are hints for a particular OS that can be ignored by other
    implementations.

I take this to mean, one can set EI_OSABI and other consumers can
typically ignore the values.


> Given that, it seems completely wrong for FreeBSD to be setting the OSABI
> field to ELFOSABI_FREEBSD, unless the relocations, header fields, etc.
> are incompatible with the stock System V ABI.

We are strictly incompatible (so is NetBSD).  Take for instance 'struct
stat'.  No BSD strictly follows the SVR4 ABI by doing:

    <sys/stat.h>: #define __STAT_VERSION 2
    extern int __xstat(int ver, char path, void *buf) 
    static int stat(char *path, struct stat *buf)
    {
            return __xstat(__STAT_VERSION, path, (void *)buf);
    }

[the purpose being to enable you to write your own libc and run
ABI-compliant applications since it's 100% dynamic linked and the apps
strictly only call libc (not the kernel).]

So this brings up the question of how close to the SVR4 ABI does one have
to be to be ABI compliant.  None of us other than the SVR4 itself 100%
ahears to the published specs.