Re: Has anyone looked at ELF 4.1?

[Roland McGrath <roland@frob.com>]

> As I read it, it's a bit different from the OLF proposal.  SCO is
> defining EI_OSABI as indicating whether the file conforms to the
> standard ELF format.  A value of 0 (ELFOSABI_SYSV) indicates that the
> file does conform.  For EI_ABIVERSION, a conforming application must
> use 0.  Our files do conform to the specification (I hope), so it is
> correct for us to use 0 for both.

I don't know how to read it.  The "standard" is hopelessly vague (if a
unilaterally published document can be called a standard).  They don't
clearly define an ELF standard independent of the SVR4 Unix ABI standard,
so when they say "this specification" I don't know whether that means "the
ELF specification" or "the SVR4 ABI specification".

One sentence is suggestive but mysterious:

	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.

It is certainly not the case that we (intentionally) use on GNU platforms
different "platform specific meanings" for any ELF structure flags or
values that are in the ELF spec.  Aside from SVR4, the one meaningful value
they list is HPUX.  Do you know of any incompatibilites between HPUX's use
of ELF and other ELF implementations?  That might suggest they are talking
about file format compatibility rather than ABI compatibility.  If that is
so, this is an utterly stupid addition.  If HPUX ELF is not compatible with
the existing ELF spec, then HP should use a different EI_VERSION value.

They have conveniently added fields to the header without changing the
EI_VERSION number (which the original spec suggests is intended for such
changes), taking bytes from the EI_PAD area that the old spec reserves to
be zero and making zero mean SVR4.  If they are talking about the ABI,
then that retroactively declares all old ELF binaries to be "officially
marked" as wanting the SVR4 ABI; that is bogus.

> However, we could perhaps ask registry@sco.com to define
> ELFOSABI_LINUX, and define that as being the same as the standard, but
> using the Linux API.  Similarly for other free operating systems.

The community of OS projects using ELF has already adopted an ABI
identification mechanism, using PT_NOTE.  Someone from SCO once said they
would use that scheme too.  But now this totally other thing comes out in
this new spec that, as far as I know, noone in the free OS community was
ever asked about.  Since it says it's a draft, perhaps we can get them to
clean up and clarify the draft and take notice of the rest of the world
that is using ELF.  

A so-called standard is not meaningful or important to adhere to just
because an organization publishes it, and a specification is certainly not
a standard just because one vendor unilaterally declares it so.  We chose
to use ELF as we do now on its merits, and in adding the ABI notes we used
a mechanism that fit in their spec and seemed in the spirit of the spec, to
be nice and try to cooperate helpfully to interoperate.  Now they want to
promulgate a new spec with changes that are not in the spirit of the old
spec and don't use its prescribed procedures for change.

I wish they would clarify their specs to clearly specify the ELF file
format and special section formats unambiguously and independent of the
operating system ABI specification.  That would allow a compilation
toolchain, linker, and dynamic linker, to be clearly correct in their
processing of ELF files independent of how they are implemented and what
ELF files they might be processing.  I don't know if anyone else attempts
to provide such a thing, but GCC, GNU binutils, and the GNU dynamic linker
that's provided in the GNU libc package (but usable independent of what
libraries it loads, as well as being easily portable), together form a
fully complete, correct (we hope) to spec, and highly-portable (not to
mention high-quality, well-supported, and permanently free) set of ELF
tools for a wide variety of processors.  I think we are all proud of this
communal work and the high standard of cross-platform uniformity and
correctness we endeavor to achieve, and it would be nice to have an
unambiguous standard to which we can be definitively correct and measured
against our proprietary peers.

I'm now going to proceed on the assumption that EI_OSABI is intended to
indicate the operating system ABI expected by the program.  I make this
assumption both because of its name, and because adding two fields whose
sole meaning is "yes, really, the same file format spec" is just plain
idiotic and I'm giving SCO a little (perhaps too much) credit for not being
chalk full of complete idiots.  If we can figure out how on earth there can
be a meaningful indicator specified in a standard format that some parts of
the format are nonstandard, maybe it will be become more clear.  Is there
anyone with a brain at SCO or HP that we can ask what the story on this
magic HPUX compatibility value and the horrifying "platform specific
meanings" vagueness?

I agree that the simple two-byte addition in the file header padding area
is nicely compact and easy to check, and if specified properly can be
appropriately and fairly done without changing the header version numbers.
What "specified properly" means is full unambiguous backward compatibility
with the reality of the old specification.  That is, a value of zero in
those positions as required by the old spec should mean "old spec, ABI not
specified" and the suggested practice in encountering such would be to look
for a PT_NOTE like every free OS has been using unambiguously for many
months now.  It is completely bogus to retroactively declare existing ELF
binaries to mean something the format didn't mean in the original spec.
If old SVR4 systems complied with the spec, they ignore those bytes anyhow,
so if they thought all ELF binaries were SVR4 ABI binaries, they won't care
that new SVR4 ABI binaries have a nonzero value in that byte.