On Tue, Mar 10, 2020 at 1:31 AM Pavel Labath <lab...@google.com> wrote:
> 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 (?) > I'm not sure anyone's really written it down, and I don't know of too many extensions (gnu_pubnames/pubtypes is another extension - but it isn't referenced from debug_info at all - a flag attribute says "this CU has a gnu_pubnames/pubtypes contribution" but doesn't actually refer to it at all - the gnu_pubnames/pubtypes contribution refers to the CU instead - so CUs don't have to be parsed at all when consulting the index) - but, yes, that's what I'd expect. > > >> 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. > Yeah, looks like it was partially done - but not quite sufficient. - Dave > > pl >
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
