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

[David Blaikie]

On Wed, Feb 26, 2020 at 6:29 AM Michael Eager <eager at eagerm.com> wrote:

> On 2/26/20 1:05 AM, Pavel Labath via Dwarf-Discuss wrote:
> > The main question on my mind now is, what is the likely future
> > direction of the DWARF spec -- if say DWARF v6 adds a new section, how
> > will it handle mixed v5+v6 debug_cu_indexes? I don't think it will
> > want to make that unsupported (1). I also doubt it will resort to
> > "subjective" DW_SECT constants, as it is easy to ensure the official
> > DW_SECT constants do not overlap.
>
> As much as possible, we try to insure that different versions of DWARF
> can be used together.

  For example, a library may have debug data in one
> version of DWARF while the program may use a different (later) version.
> That is, we try to maintain forward compatibility whenever possible.
>
> We also try to insure that an older consumer can accept newer versions
> of DWARF, skipping over the parts that it does not understand.
> Sometimes this may mean reduced functionality, but it should not result
> in failure.
>

Is there a sense of what "uses" are goals/non-goals there? For instance:
not being able to read a cu_index would make a DWP file unusable, so having
a length prefix wouldn't be especially important/useful there. But for
dumping tools - that might want to dump an index, if they understand it,
but otherwise skip over it & dump other things (even if today we only
expect one index in a DWP file - nothing to say a producer couldn't
squirrel away a side channel/extra data in that section, etc - or that a
future DWARF version might do it) - is that a valid "use" in this context?

(similarly, or perhaps more motivating - with debug_macro, currently having
no length field (especially as a prefix before the version) - a
dumper/other user can't skip over the parts they don't understand & would
have to give up entirely)

I'm not sure there's much use case, except for dumping/analysis tools, in
having older tools support newer versions - for debugger-style use of
debug_info (& now the debug_line section) you tend to have to start with
the debug_info section, and if the version number is rev'd there, then the
parser must skip that CU and never discover everything it references. I
guess that's enough - having the length prefix so debug_info and debug_line
contributions can be skipped over is important. Having it in other sections
that you're usually only meant to read when they're referenced from
debug_line/debug_info is less important - only useful for dumping tools
that want to go and look at everything.

HTH
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20200309/98a30a2b/attachment.html>