This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: EI_ABIVERSION usage
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: obrien at FreeBSD dot org
- Cc: Jason R Thorpe <thorpej at wasabisystems dot com>, Geoff Keating <geoffk at redhat dot com>, binutils at sources dot redhat dot com, Richard dot Earnshaw at arm dot com
- Date: Wed, 08 May 2002 12:07:42 +0100
- Subject: Re: EI_ABIVERSION usage
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw 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.