Re: EI_ABIVERSION usage

[Richard Earnshaw <rearnsha at arm dot com>]

> > 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.

It's clear from the level of heated debate on this subject that the 
specification does not clearly show the intent of this field.  I still 
feel this is the case, and would welcome a definitive ruling by someone 
who has an authorative position on this.



> 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.

I hadn't seen this posting before, thanks for pointing it out.

>     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.

Having read the above, I'm no-longer sure I agree.  I think the key to 
interpreting this field is (quoting from Cary):

    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. It works just like the e_machine
    field does for attaching meaning to processor-specific values and
    flags.

>From this it would appear to me that the *intent* of this field is only to 
aid in the interpretation of OS-specific bits *in other ELF fields* as has 
been claimed by others.  Note the analogy to e_machine, and the 
application of the meta-principle: e_machine specifies ELF header 
extensions specific to the machine, so EI_OSABI specifies ELF header 
extensions specific to the OS.

This still leaves open the major question of how we should detect os 
run-time variants and extensions.  It's clear that none of these OS'es can 
be truly SVR4 compliant, since most programs will include stdio.h and 
hence bring in a FILE type pointer which is unlikely to be compliant with 
the specification.  However, I do have to concede now that it is not clear 
that EI_OSABI was intended for this -- again extending from Cary's last 
parargraph:

    For statically-bound programs, I'm afraid we don't have a clear
    solution. We took the general approach that such programs are 
    not ABI-conforming in the first place, and can use any 
    mechanism they might choose to verify that they are executing 
    on the appropriate implementation.

We are in a similar situation here, we have a program executable that is 
tied to its execution environment in some way: the ELF spec, sadly, has 
nothing explicit to say about how this might be detected.

R.