On Mon, 9 Mar 2020 at 23:13, David Blaikie <dblai...@gmail.com> wrote: > > > > On Wed, Feb 26, 2020 at 1:05 AM Pavel Labath <lab...@google.com> wrote: >> Yes, the lack of an official extension space is unfortunate, but I >> don't think this needs to be a blocker -- the spec also doesn't >> include an DW_FORM extension space, but that hasn't stopped people >> from inventing new forms. I would say that the situation is much >> better here actually -- it's quite easy for a consumer to ignore an >> unknown DW_SECT constant, whereas an unknown DW_FORM pretty much means >> you need to throw away the whole unit. >> >> Thinking about this further, the lack of a DW_FORM extension space is >> probably a reason for not introducing a DW_SECT extension space -- >> it's hard to imagine how someone could meaningfully add a new section >> without a new form to refer to it. > > > Yeah, not many come to mind, though macro seems like the perfect example. Had > debug_macinfo made through to DWARFv5, GNU might've still wanted the > debug_macro extension & being able to define a new column would've worked > fine without the need for new forms (GNU extension debug_macro support used > an extension attribute (DW_AT_GNU_macros) but an existing form > (DW_FORM_sec_offset) - and the things in macro aren't referred to otherwise > (unlike loclist and rnglist) and even if tehy did could probably use existing > forms but extension attributes, etc).
That is a very good point. It is possible to refer to a new section through a custom attribute with an standard form. Maybe that should even be the recommended way of introducing extension sections, as it does not prevent successful parsing by consumers unaware of the extension (?) >> The option (3) sounds plausible -- I do appreciate the cleanliness of >> having a v5 index containing v5 units only, and follow it with a v6 >> index with v6 units. But I am not sure if that's the direction I would >> take, because I also very much like the idea of having just a single >> index table to access all units. > > > Yep - unless someone has significant objections my plan is currently: > > Emit a v5 index with extension/non-standard extra column indexes > (specifically: DW_SECT_LOC and 9 and DW_SECT_MACINFO at 10). I hope those can > at least be reserved (like DW_SECT value 2 (originally DW_SECT_TYPES) was in > DWARFv5) in DWARFv6. & maybe open up an extension space in the future. That sounds good to me. When I saw that number 2 (debug_types in the fission extension) was reserved, I originally assumed this was what had already happened. pl _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
