I'd rather not see these tags in the gABI, because they
facilitate a model of development that we (Solaris) don't
support. The merit of Cary's NONCOMFORMING suggestion is that
it's far easier for abstaining implementations to opt out. Of
of course, there's always the OSABI arena, which I think might
be the better fit here.
Regarding the OSABI, EI_ABIVERSION is defined relative to
EI_OSABI, meaning that it has a different meaning depending
on which OSABI the object specifies. I could see bumping it
helping a specific ABI (e.g. OSABI_GNU), but I don't know that
it has an impact on generic features.
Byte e_ident[EI_ABIVERSION] identifies the version
of the ABI to which the object is targeted. This
field is used to distinguish among incompatible
versions of an ABI. The interpretation of this
version number is dependent on the ABI identified
by the EI_OSABI field. If no values are specified
for the EI_OSABI field by the processor supplement
or no version values are specified for the ABI
determined by a particular value of the EI_OSABI byte,
the value 0 shall be used for the EI_ABIVERSION byte;
it indicates unspecified.
Longer, more details that you probably care less about...
I don't believe that we document a required behavior
for this. It's one of those unspecified implementation details.
think we probably inherited our behavior from SVR4.
I didn't know the answer off hand for Solaris, so I did a quick
experiment, by editing an object to set phdr and dyn items to
unknown types. It seems that Solaris does ignore unsupported
program headers and dynamic tags. The link-editor (ld) on the
other hand, objects to unknown section types. On the surface,
this might seem inconstant, but it really doesn't matter,
because we don't want to support that model. We intend for
the linkers to always understand everything they are given.
If that's not the case, it indicates a "time traveling" object
built by newer linkers, something we explicitly rule out of bounds
Our approach (which is part of the Solaris backward compatibility
guarantee) is that we support old objects running on new systems,
but explicitly rule out the reverse (new object, old system).
The user is required to build on the oldest system they want
to support, and we guarantee that it will work on anything newer.
In this model, the scenario where we encounter unknown types
just doesn't happen except by accident, and the answer is always
"don't do that". You might think that people dislike this, and
perhaps some individuals do run afoul of it and resent having
to change their process, but overall, it's been pretty drama free
over many decades of SunOS. It has the merit of being easy to
explain and understand.
Easier said than done of course.