[Dwarf-Discuss] DWP mixed (DWARFv4/pre-standard + DWARFv5) content

[David Blaikie]

On Tue, Mar 10, 2020 at 1:31 AM Pavel Labath <labath at google.com> wrote:

> On Mon, 9 Mar 2020 at 23:13, David Blaikie <dblaikie at gmail.com> wrote:
> >
> >
> >
> > On Wed, Feb 26, 2020 at 1:05 AM Pavel Labath <labath at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20200310/eed79ead/attachment.html>