On 12/1/23 18:01, David Anderson via Dwarf-discuss wrote: CAUTION! External Email. Do not click links or open attachments unless you recognize the sender and are sure the content is safe. If you think this is a phishing email, please report it by using the "Phish Alert Report" button in Outlook.
On 12/1/23 16:17, David Blaikie wrote: On Fri, Dec 1, 2023 at 1:43 PM David Anderson via Dwarf-discuss <dwarf-discuss@lists.dwarfstd.org<mailto:dwarf-discuss@lists.dwarfstd.org> <mailto:dwarf-discuss@lists.dwarfstd.org><mailto:dwarf-discuss@lists.dwarfstd.org>> wrote: On 12/1/23 05:24, Ben Woodard via Dwarf-discuss wrote: > My reasoning is that the reason why we are running out of vendor defined > space is that within in the various vendor spaces the encoding space is > consumed by legacy extensions that: > 1) were never implemented publicly > 2) were implemented but are no longer in use because the compilers that > generated them have been abandoned > 3) were in use but have been incorporated into the standard version of > DWARF. > > I feel like clearing those out by drawing a line in the sand and saying > that extensions which existed in previous versions of DWARF do not > necessarily mean the same thing once the new version of DWARF is > released, should clear out the legacy cruft such that there should be > sufficient encoding space for new producer extensions. > While clearing-out of attributes etc that were never implemented makes sense, I think the rest of this goes way too far in re-using things. There is a distinct danger of making it impossible for a consumer to read DWARF3 once DWARF6 is complete. That seems to me to be a bad idea. Unappealing. Not sure I follow this - you could still read DWARF3 as DWARF3 no matter what changes in DWARF6, I think? Could you flesh out what you're thinking here/how DWARF6 completion could (if we took some of these suggestions) cause DWARF3 to be impossible to consume? So, suddenly, a bunch of DWARF that said useful stuff now says nothing meaningful...because it had to be skipped. Or (for example) the new and old meanings of that AT code are readable both ways, yet mean very different things. How is one to know? Having stuff stop working in whole or in part is a thing big companies do (all the time?) and I hate it. (hand-wavy). As of now libdwarf reads DWARF2 and later as well as possible (nothing perfect) and losing the capability of that (or having to do things like look at the producer id (or?) to get something right) does not appeal. To me. Maybe it's just me, but I suspect we're really going overboard just to make more room for DW_OP, and it's going to take serious amounts of time all around that won't really help anything much. A very simple registry would, IMO suffice, on dwarstd.org? Temporary registration? MIPS reserved ten or so DW_AT_MIPS about 1991-1993 (I forget what yr/month it was) because there was a vague concern about waiting to reserve being bad somehow. That everyone would just step on other folks codes. And there was no internet yet (just usenet). We did nothing about those DW_AT_MIPS as the optimizations were created differently than we expected. Everything is more than a bit different now! We had a similar issue with the Concurrent-defined tags & attributes that we added in our compiler products, especially our Ada products, back in 1993 or so. It never even occurred to us that vendors would try to coordinate tag & attributes values, assuming that each vendor got to use the extension space however it wanted. So we have regions of overlap with other vendors: * DW_TAG_* 0x4081 - 0x4093 * DW_TAG_* 0x4100 - 0x4109 * DW_AT_* 0x2001 - 0x200a * DW_AT_* 0x2100 - 0x2153 Once we started seeing the same tags & attributes from other vendors, sometimes even linked together in the same executable, we started having to check the DW_AT_producer string to determine if they were coming from Concurrent compilers, or other compilers, so they could be positively identified. We weren't happy about this, but that history happened and we couldn't go back and change it. (One place that was particularly clunky was an internal patch to binutils' readelf.) This plan for reuse would impose a similar requirement on consumers, but instead of checking the producer, it would be checking the DWARF version for each value in the extension range. Or, for older tags & attributes with overlaps (like ours and evidently HP's), perhaps both. Moreover, it would be checking the DWARF version even if there was no potential confusion, just to differentiate between a known meaning and "rejected by fiat". It seems like consumers would be just as unhappy about having to do this! Also, a little bit of historical counterargument: In the DWARF 2 spec, even though it was a radical departure from the DWARF 1 spec, some tag & attribute values from DWARF 1 were reserved in DWARF 2 just to avoid confusion (e.g. tags 0x06, 0x07, 0x09, 0x0c, 0x0e). So that was a choice made even for the spec-defined values. This is a bit apples & oranges, but I think it's interesting that the thinking back then was the exact opposite: never reuse values. Todd Allen Concurrent Real-Time
-- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
