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

[David Blaikie]

On Sun, Mar 29, 2020 at 3:44 PM Cary Coutant <ccoutant at gmail.com> wrote:

> >> > 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.
>
> The pre-v5 dwp format was just a prototype, accessed via
> --experimental GCC flags, and I don't think we ever intended to
> support mixing pre-v5 dwo files with standard v5 dwo files. I'd
> recommend your original option #1 (invalid/unsupported). Thus, you
> shouldn't need DW_SECT_LOC or DW_SECT_MACINFO.
>

That'd be really difficult (I think I'd go so far as to say - it wouldn't
be done that way) for an environment like Google (or other large projects)
that want to change the default. It's important not to get into a situation
where the flag flip from v4 to v5 is overridable, so that we can readily
opt-out of v5 on a per translation unit basis if there happen to be a
handful of translation units that trip over uncommon bugs without having to
rollback the whole codebase each time we hit something like that.

So I'd say at the very least, I think we'll implement a v4+v5 index in our
internal port of binutils/gold dwp and gdb - and I'd really hope to be able
to upstream those for anyone else who might be in a similar situation.

I guess it's possible we could opt-out of split DWARF and opt out of v5 for
such translation units (though there's currently no flag to undo
-gsplit-dwarf on the command line  -ah, there is in GCC (-gno-split-dwarf)
but not in Clang, so we could add that). Does make things a bit awkward,
but not impossible, and seems like in the future we're going to have to
keep backwards compatibility too, so wouldn't be so bad to keep it for v4
too, would it?


>
> The .debug_types sections were moved back into .debug_info sections at
> the very last minute, so we just removed DW_SECT_TYPES without
> renumbering the later values. As best I recall, that was just a nod
> towards some compatibility with the prototype format, but it wasn't
> intended to provide for complete compatibility.
>
> I don't believe we ever supported .debug_macinfo in the prototype, so
> I wasn't concerned with the renumbering around DW_SECT_MACRO and
> DW_SECT_MACINFO.
>
> I agree that we should have reserved an extension range for DW_SECT
> values. It's probably safe to pick some arbitrarily large values if
> you need to extend this.
>
> For DWARF-64 support, I truly hoped that we wouldn't ever need it, but
> if it was ever necessary, the mechanism I had in mind was to simply
> replace .debug_cu_index sections with .debug_cu_index_64 sections (and
> likewise for .debug_tu_index). Maybe DWARF v6 will address this. Keep
> in mind that the .dwp can be an ELFCLASS64 object file, and its total
> size can grow larger than 4GB, even if .debug_cu_index can't support
> any section offsets larger than 4GB.
>
> -cary
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20200330/f974dcd3/attachment.html>