On 8/12/22 5:34 PM, ali_e...@emvision.com
> Let me ponder this
> for a day or 2, and let's see if anyone else has an opinion.
I've taken a few days to think about this and to get
some clarity. I still don't want to see all of those early
GNU additions added to the generic ABI, even though it's
true that I could probably work around it if it happened.
I'd like to explain why.
The items in play here, primarily GNU hash, but also other
things such as symbol versioning, predate the creation of a
gABI, and of the OSABI partitioning that resulted. For that
reason, there seems to be some disagreement about what is
required for them in terms of setting an OSABI. Now that
OSABIs exist, do you have to set them for things that are
older than that?
There are items, such as DT_FLAGS_1, or DT_GNU_HASH, that
were really not generic, but which were added by various
implementations, rather than coming from Bell Labs with
the original ELF. These are extensions made before the gABI
happened. Folks would grab a value, hope that no one else had
grabbed the same one, and forge on. These things inevitably
started colliding, which eventually led to the gABI meetings
some 20 years ago that created the gABI, and OSABIs. There's
really no alternative to grandfathering in these items, and
doing our best to not step on each other's toes. No OSABI
There are other items, such as SHT_GNU_HASH (aka SHT_SUNW_SIGNATURE)
that also predate the gABI, but which today lie in OSABI territory,
and for which different OSABIs have assigned different meanings.
Even in cases (verdef, verneed, versym) where we all agree to
the basic meanings and have the same numeric values, the actual
semantics differ. We both have ancient claims to these values,
but the collision today is the point, rather than who was first.
That leaves GNU hash in the awkward position of being partially
grandfathered (DT_GNU_HASH) and partially, possibly, not
(SHT_GNU_HASH). Did no one notice this in 2002?
Even if I thought it made sense otherwise, I can't say yes to
this, because of the existing OSABI range collisions. 0x6ffffff6
can't be SHT_GNU_HASH on Solaris because it is already SHT_SUNW_SIGNATURE.
And so on for other examples, such as versioning. Were I to
implement GNU hash, I would have to assign the section a different
number. Names are are useful nmemonics, but the numeric values are
what makes an ABI, and some of these numbers are already taken.
For the OSABI concept to be useful, the only way I can see it
working, is that whenever an object uses values from an OSABI
range, the ELF header needs to declare an OSABI to establish
the namespace under which those values are interpreted. I think
this needs to be true whether or not the feature predates OSABIs,
because otherwise, the situation is ambiguous. I understand that
this isn't what's done today on some platforms, but I still haven't
heard a convincing explanation of why it shouldn't be.
- Why can't a GNU conforming platform set ELFOSABI_GNU even
if they don't implement IFUNC, or other post-gABI features?
- If there are reasons, then why shouldn't that platform be
expected to have their own OSABI, that includes the GNU
features they want to have? I'm sure there would be no
problem giving them an assignment, if they don't actually
already have one. It's no different than a machine assignment,
and no harder to acquire.
A different reply suggested that the whole world is now GNU,
and in not wanting these features in the gABI, I am forcing
an unreasonable inconvenience on everyone else. My main problem
with this is, to quote Monty Python, "We're not dead yet!". Not
only are we not dead, but we're certain to be around for at least
another decade (my opinion, you can make your own estimate). You
knew this club had other members when you joined it. :-)
In the meantime, the gABI is a shared space, and it's best if
we can figure out how to coexist. A month doesn't go by where I
don't think "Thank Goodness that GNU adopted ELF, and worked
for a gABI, rather than inventing some ELF-adjacent, but
incompatible, format of their own". Had they made that very
Microsoft-like move, the rest of us would be in a much worse
position today, probably with no compilers, and limited ability
to build open source software. There were benefits: A proven
solution, a community to share ideas and improve them,
the general benefits of wider communication. There are certainly
downsides as well: You have to make it work when things aren't
what you'd choose to do otherwise. You sometimes have to work
with folks you might otherwise ignore. Nonetheless, I think it's
been great. I've had a lot of help from folks in the GNU
community over the years, for which I am very grateful.
I don't want to inconvenience anyone, and I trust that over
the years, that's been apparent. But what is the nature of
the actual inconvenience? Is it really a big deal to set a
field in a header to a predefined number that identifies the
scope for that object?
eh.eh_ident[EI_OSABI] = ELFOSABI_you
And then, do whatever you want, within your scope
free and clear? This scheme is 20 years old, and GNU
were in that room when it was decided. Why was it agreed
to then, why is it a problem now, and what exactly is
the difficult part?
If the whole world is GNU, then all the objects will
be ELFOSABI_GNU. That's not a problem as far as I can see.
It doesn't stop you from doing anything you'd otherwise do.
Today, it might look like Solaris vs a 'pretty "universal"
feature', but any time you have more than one party, there will
eventually be a desire by one of them to do something
differently. You might all be aligned right now, but that
may not always be the case. As an old Unix guy, I often
note how the "Unix Wars" of the past have been replaced
by "Linux Distro Wars". There's nothing new under the sun.
We have a good mechanism in place for dealing with this --- I
say let's use it, and carry on.
Of course, the world isn't going to end if I trip over an
obviously GNU object that doesn't have its OSABI set. It
happens all the time. Still, it simplifies things if they do.
I don't think we really have a disagreement about the OSABI
notion itself, but perhaps it's time we clarified what's
expected around these preexisting, but not gABI, items, so that
we can put this issue to bed and not have to bring it up again.
It would also make sense to compile a list of those things,
as an addendum to the gABI, to make it easier for everyone
to identify them. However, these are by definition, anything
in the gABI partition that isn't in the gABI, so it's not
that hard to intuit.
To bring this long digression to a point:
- I think that objects that omit DT_HASH should
define an OSABI under which that omission makes
- I support adding a generic DT_ entry for specifying
the size of the .dynsym, to facilitate that.
- I don't think that the GNU hash needs to be part of
the gABI to justify dropping DT_HASH, or that moving it
to the gABI makes any difference to the ability of
various platforms to use it. The gABI isn't better
or worse than an OSABI. It's just a different, shared,
Thanks for listening.