>ECOFF really isn't a bad executable format.

>For one thing, unlike many other -- ELF in particular -- it actually has an
>OS type field, in addition to a machine-type field.  Since I now have to
>deal with *three* different OS flavors of ELF on the i386, two of which don't
>use any sensible method at all for indicating that their binaries use their
>particular ABI and one of which uses a method that even its own variant of
>'file' can't distinguish (but, thankfully, its kernel can), it's hard for me
>to see ELF as a good choice.

>Can someone actually enumerate some good reasons for using ELF rather than
>ECOFF, our own extended a.out, or, say, OSF/ROSE?  Each has some drawbacks,
>but none seemingly so severe as ELF's lack of an OS-type header field.

The ELF ABI specifies how functions are called.  It is expected that a
binary will be dynamically linked against libc.so.  So, in principle,
details of system call handling can all be hidden in libc.so.  In
practice, there seem to be some problems.

The easy solution is to use a different interpreter program.  I
believe that is how Linux distinguishes SVR4 binaries, for example.

This doesn't help for statically linked programs, which aren't defined
by the ELF ABI.  The simplest solution, if this really is an issue, is
probably to define a new byte in the e_ident field in the ELF header.
It would be easy to add an option to the linker to set that byte, and
different defaults could be used for different operating systems.  In
short, this would introduce an OS-type header field.  I would install
patches to this effect in the GNU linker.  An ambitious person would
propose the extension to the ELF maintainers (currently, I believe
this is SCO).

The main advantages to ELF are the ability to have an arbitrary number
of sections, a clean and comprehensible interface for dynamic linking,
the ability to specify alignment on a per section basis, and easy
extensibility when needed.  ECOFF and a.out have none of these
characteristics (if you think that ECOFF permits an arbitrary number
of sections, you should examine the format of relocation entries).
ECOFF also suffers through having an overly complex symbol table
format, which slows down the linker.  Both ECOFF and a.out suffer from
mixing debugging information into the symbol table, which slows down
the linker.

I think that somebody else commented that it was difficult to tell
whether an ELF program was dynamically linked.  Actually, it's
relatively simple: just see whether there is a PT_INTERP program
header.

Ian