On 11/2/21 5:19 AM, Florian Weimer wrote:
> This is not about providing compatibility, but providing at least some
> form of diagnostics rather than a mysterious crash. Crashes caused by
> missing (not applied) relocations are rather difficult to diagnose, so
> I'd really like to have something better here.
> The idea of a gradual phase-in is nice, but it's not what has happened
> at all on the consumer side (where it is most important).
> I would really appreciate if we could address the issue that loaders are
> currently expected to ignore unkown dynamic tags and program header
> tags, even in cases where it is clear due to the way the binary is
> constructed that ignoring these tags will not lead to a usable process
> image. DT_REQUIRED works for me if we can get flags assigned as needed
> (without having this very discussion over and over again for each
> individual flag). My previous proposal side-stepped the assignment
> issue, but apart from that it is equivalent.
> If DT_REQUIRED is adopted, link editors for GNU/Linux would likely
> increase ABIVERSION if DT_REQUIRED is generated (with a non-zero value),
> to get the expected failure behavior from existing dynamic loaders that
> don't know about DT_REQUIRED.
OK. I'd also appreciate not having this discussion
over and over, so we have at least that as a common
interest. :-) And of course, a clean error message is much
easier for end users to understand than starting at a
core file. Mistakes happen, and good errors are never
a bad thing.
My first question for you is about this not being to
provide compatibility. As I said, I've always found it
questionable that unknown things are ignored. Suppose
we were to simply modify the linkers to reject such
objects? I don't recall the ELF spec saying that unknown
things should be ignored and think that this is just
one of those implementation things (I could be wrong --- I
didn't look before typing this).
The biggest impact of that is that using new features will
force new linkers to be installed first, but in today's world
with package managers and online repos, and continually updated
bits waiting to be pulled down, is that as big a deal as it
used to be? It sure would be nice to solve this without
needing to extend ELF.
Assuming that my previous suggestion is too rigid to
gain support, let's forge on and explore what we might
do to allow the compilers to label things that must be
understood and supported.
A weakness of DT_REQUIRED, as proposed, is that new
bits need to be assigned for it, as new features get
added. Not only is this an added layer of bureaucracy,
but as things age, the older bits become pointless. In
5-10 years, no one will need to say "RELR is required",
but that bit in DT_REQUIRED will live on, taking up space
in objects, documentation, and our heads.
Problem #2: As a gABI feature, DT_REQUIRED can only label
gBI features. I bet you'd love to be able to label OSABI
and psABI features too, wouldn't you?
Another issue occurs when an old linker, sees a new bit
set in DT_REQUIRED that it doesn't understand. The presence
of that unknown bit means that we can't continue, but since
we don't know what the bit means, we're limited to an overly
ld.so.1: foo.so: unrecognized requirement 0x2 in DT_REQUIRED
The idea of using a new flag from DT_POSFLAG_1, or something
similar to it, to mark dynamic items that can't be ignored
solves most of these issues:
- Once defined, it doesn't need ongoing ABI maintenance,
and can be applied to any dynamic tag, old/new,
- Compilers can quit setting it for tags that have
aged long enough to be ubiquitous.
- The error message that can be produced can actually
reference the thing that isn't understood:
ld.so.1: foo.so: unsupported dymamic tag:  0x<tag value in hex>
That doesn't help with program headers, or section headers.
For program headers, we could create a PT_REQUIRED flag.
Same for section headers, but since section headers aren't
used by the runtime linker, perhaps it's not necessary to
I do think that a better name than REQUIRED, like MUSTSUPPORT,
might make all of this more clear. As noted, REQUIRED does
seem like something that would apply to a NEEDED dependency.