This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: EI_ABIVERSION usage
On Wed, May 08, 2002 at 12:07:42PM +0100, Richard Earnshaw wrote:
...
> 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
I hope it is clear to everyone (after Richard's correction, of course) and
we can close this issue for goodd now.
> 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.
The runtime implementation is free to do whatever it wants. But it is not
the concern of binutils.
H.J.