<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>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.<br></div>
        </div>
      </div>
    </blockquote>
    <p>In most cases, I can see your point but in this case I cannot. To
      me this seems obvious. </p>
    <p>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.<br></p></div></blockquote><div>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.<br><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p>
    <blockquote type="cite">
      <div dir="ltr">
        <div dir="ltr">
          <div>6. Re 6.1.1.2 and <a href="http://6.2.4.2" target="_blank">6.2.4.2</a>: 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<br></div>
        </div>
      </div>
    </blockquote>
    <p>There was specific text in those sections which seemed to need to
      be changed.<br>
    </p>
    <blockquote type="cite">
      <div dir="ltr">
        <div dir="ltr">
          <div><br>
          </div>
          <div>7. Re 7.1: There seems to be text missing between "where
            there is a vendor" and "but it can also".</div>
          <div><br>
          </div>
          <div>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?</div>
        </div>
      </div>
    </blockquote>
    <p>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. </p>
    <p>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. </p>
    <p>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.</p></div></blockquote><div>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).<br><br>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.<br><br>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".</div></div></div>