[llvm-dev] [DWARF] De-segregating type units and compile units

[David Blaikie via llvm-dev]

A few general design discussions that cross multiple patches, so figure
it's worth discussing here:

The DWARFUnitSection is currently (before your changes) representing the
contents from a single section - and most/all of the classes in
libDebugInfoDWARF use "parse" to initialize their complete state. So it's a
bit novel/new/different/worth considering (maybe renaming the function or
the like) what it means to make this class now represent data from multiple
sections and to be documentend/intended to be used to aggregate the parsing
result from multiple sections (both multiple sections with the same name
(debug_types currently, or in v5 debug_info comdat sections for type
units)). One observable part of the matter of which sections come from is
the section relative offsets (you'll see the difference in dumping a file
with at least 2 types with type units enabled, with and without split DWARF
- without split DWARF comdat sections are used, so each types section
offsets are zerod at the start of each type unit because it's a separate
section (even though it has the same section name) - whereas in split
DWARF, in the .dwo file the offsets are across the whole, singular,
debug_types.dwo section)

As for virtuality in the unit hierarchy - reckon it's worth it, or maybe
just use a union/conditional for the dumping differences (& collapse/remove
the type distinction between type units and compile units - just have
DWARFUnit as the only unit class)? (since it's just the type_signature V
DWO_id (maybe we could generalize that to "id") and type_offset that's
different between them).

On Tue, Jul 24, 2018 at 10:40 AM via llvm-dev <llvm-dev at lists.llvm.org>
wrote:

> Hello DWARF fans,
>
> I've just posted a set of four refactoring patches for DebugInfo/DWARF,
> which move in the direction of handling DWARF v4 or v5 type units and
> compile units more coherently.
>
> In DWARF v4, type units and compile units are strictly segregated into
> the .debug_types and .debug_info sections, respectively.  This division
> was pretty ingrained into how DebugInfo/DWARF handled the units.
>
> In DWARF v5, type units and compile units are all in the .debug_info
> section, and the .debug_types section is obsolete.  So, we need to have
> a container than can handle both kinds of units in a straightforward way.
>
> The refactoring replaces a pair of collections templated on the unit type
> with a single collection whose elements are base-class pointers; thus it
> can contain elements that are a mix of unit kinds.  Everything that really
> mattered was either already virtual or was straightforward to convert to
> generic handling.  I think I needed only one type-based conditional, on
> top of what already existed.  The code doesn't *quite* support DWARF v5
> type units in the .debug_info section, but the new starting point should
> make that straightforward.
>
> In a mixed v4/v5 executable, we can pretend the .debug_types sections
> are all really .debug_info sections, and tack them onto the end of the
> vector of units that already handles a mix of compile and type units.
> This is also how the LLDB DWARF parser handles this case, so it's at
> least consistent in principle (even if the actual code differs).
>
> The existing distinction between "normal" and split (DWO) units remains;
> that has to do with what information exists in which object files, and
> is not fundamentally changing in DWARF v5.
>
> Patch 1: De-templatize DWARFUnitSection
>          https://reviews.llvm.org/D49741
> Patch 2: The TU collection doesn't need to be a deque
>          https://reviews.llvm.org/D49742
> Patch 3: Rename DWARFUnitSection to DWARFUnitVector
>          https://reviews.llvm.org/D49743
> Patch 4: Unify handling of type and compile units
>          https://reviews.llvm.org/D49744
>
> Thanks,
> --paulr
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180725/bd3eae87/attachment.html>