[Dwarf-discuss] Enhancement: DWARF Extension Registry

[David Blaikie]

>
> 5. Re 1.3.13: Blaming "reduced tool compatibility" on the skipability of
> unknown constructs seems a huge and unjustified claim. I don't buy it.
>
> In most cases, I can see your point but in this case I cannot. To me this
> seems obvious.
>
> Of course a consumer should be able to skip over something that it doesn't
> understand. However, if a consumer wants to achieve full compatibility with
> the producer, it needs to be able to interpret those constructs. It can't
> skip over them. That seems unquestionably obvious to me. So that the
> consumer's author can write the code that allows the consumer to interpret
> these producer specific constructs, the text refers the consumer to the
> registry.
>
I think the point might be, or a related point I would make is that DWARF
Consumer compatibility is complicated (think of DWARF as somewhere between
XML and HTML - there's a lot of "here's some tags and attributes, use them
as you see fit, here's some things we think they might be useful for") -
it's not tightly specified enough to constrain every consumer and producer
to interoperate identically, unlike something like HTML. The diversity of
languages, new language features, etc, is just wider than the DWARF
committee can effectively sign up to precisely describe.

So, while, a convenient mechanism to skip unknown constructs certainly
lowers the cost to ignoring unknown constructs, and thus lowers the cost to
incompatibility - the greater costs, of actually implementing the
functionality once a producer understands these constructs seems so much
higher that I don't think skippability significantly changes the costs of
compatibility. If none of these constructs were skippable, we'd need the
registry more than we do, but I think most consumers would just make a
table from the registry so they could parse everything, then keep ignoring
the bits that aren't relevant to their use case.


> 6. Re 6.1.1.2 and 6.2.4.2: Why single these out? This is no different
> than any other producer-defined extension and should be covered adequately
> by the general discussion in 7.1
>
> There was specific text in those sections which seemed to need to be
> changed.
>
>
> 7. Re 7.1: There seems to be text missing between "where there is a
> vendor" and "but it can also".
>
> By tieing a producer-defined extension to a particular version of DWARF,
> does that mean that when a new version of DWARF comes out that
> producer must re-register the extension to keep "ownership" of the code?
>
> I would say that as part of the new DWARF version release process, asking
> the producer developers who have registered extensions if those extensions
> are still meaningful and useful in the context of the new DWARF version.
>
> If so, then it gets carried over. However, If some particular extension
> continues to be useful across many versions of DWARF and producers are
> still actively using it, then that extension should be considered for
> standardization.
>
> If the extension has been standardized as part of the new DWARF version
> then that producer specific encoding can be reused in the context of the
> new DWARF version. In other words, producers should prefer the standardized
> way of expressing a concept over a producer specific way.
>
So that's certainly something we haven't done in the past (reusing the
existing extension encoding as a standard encoding) perhaps partly due to
the lack of such a registry - but also the point of the user extension
space is to be unconstrained. While we might've documented the extensions
we know about - this extension encoding space might be used by someone else
in some other way we don't know about (maybe that's a bit theoretical).

Another reason we haven't reused any encodings, even standard ones, is it
complicates consumers - they're probably going to end up needing an
encoding space that covers all the versions of DWARF they support, so
they'd need to remap all the DWARF version-specific encodings into one
wider encoding space that covers all the DWARF versions and encodes each
entity uniquely (alternately: having to check the DWARF version each time
when trying to lookup any attribute would add an extra indirection to every
attribute test, for instance... which would be a bit rough - I expect it
wouldn't outright/catastrophically harm performance, but would probably be
pretty difficult to work with), so I think that's generally why we haven't
reused any encoding space - either in the standard, or in extensions,
because consumers would struggle with it.

But worth looking at that kind of decision and re-evaluating, perhaps. I
think that's probably the core issue being proposed/that'll need to be
discussed here, is "can we reuse encoding space/what's the cost/impact of
that".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20231201/acff601d/attachment.htm>