ELF has a scheme in which numeric ranges are partitioned into
generic, OS, and platform ranges. Generic items must be identical
on all ELF systems. The OS and platform ranges are under the control
of the individual entities that develop each system, and need not
be compatible (though it's better if they are).

As part of this scheme, there was an agreement made (before my
time, not sure about the details) that an object that uses any
OS or platform specific details should identify itself using the
e_ident[EI_OSABI] ELF header element. That would allow the reader
to apply the right interpretation to the OS and platform values
found therein. A value of 0 means "no extensions or undefined".
Codes have been assigned for the various operating systems (linux
is 3, solaris is 6, and so forth). However, as far as I know, we're
all still setting this value to 0.

Instead of explicitly tagging our objects, we've all been trying
very hard to make sure that the new values we add in the OS and
platform
ranges don't conflict with those of others. I think this is a very
good thing, and hope it will continue. However, I've been comparing
Solaris and Linux ELF objects recently, and have become aware of some
collisions in the assignment of section types:

    Value         Solaris                             Linux

--------------------------------------------------------------------------- -------------------
    0x6ffffff5    SHT_SUNW_cap                SHT_GNU_ATTRIBUTES
    0x6ffffff6    SHT_SUNW_SIGNATURE   SHT_GNU_HASH
    0x6ffffff7    SHT_SUNW_ANNOTATE     SHT_GNU_LIBLIST
    0x6ffffff8    SHT_SUNW_DEBUGSTR    SHT_CHECKSUM

So I'd like to ask: Isn't it time to start setting e_ident[EI_OSABI]?

There was some discussion of this last fall when we met at Intel,
but nothing definite came out of it. At the time, I got the impression
that people didn't think it was necessary, at least in part due to a
perception that there are no known conflicts. That doesn't seem
to be the case however.

- Ali