[lldb-dev] RFC for DWZ = DW_TAG_imported_unit + DWARF-5 supplementary files

Jan Kratochvil via lldb-dev lldb-dev at lists.llvm.org
Wed Aug 23 14:06:11 PDT 2017


at least Fedora Linux distribution uses DWZ to reduce DWARF debug info size:

It is DWARF optimization - not really a compression.  One can find it by
 <0><b>: Abbrev Number: 103 (DW_TAG_partial_unit)
    <c>   DW_AT_stmt_list   : 0x0
    <10>   DW_AT_comp_dir    : (alt indirect string, offset: 0xe61c)
 <1><14>: Abbrev Number: 45 (DW_TAG_imported_unit)
    <15>   DW_AT_import      : <alt 0xb>

I have already made some attempt for its implementation:

But I found that approach as a dead-end because LLDB expects all the DIEs from
a CU really belong to the same DWARFCompileUnit.  Contrary to LLDB
expectations the patch above creates different DWARFCompileUnit for each
DW_TAG_partial_unit.  This the patch solves for cross-DIE references but then
it ends up with:
	Assertion `!Parent || &Parent->getParentASTContext() == &Ctx' failed.
as GetCompUnitForDWARFCompUnit() is returning different clang context for DIEs
from DWZ supplementary files (different SymbolFileDWARF) vs. base file CUs.
I tried to generate alternative user_id_t to always refer to originating CU in
the base file but it is more and more complicated.

Therefore I would like a new approach to keep all the DIEs from
a DW_TAG_compile_unit incl. all its imported DW_TAG_partial_unit in the same
DWARFCompileUnit.  So far I wanted to prevent expansion/copy of all
DW_TAG_partial_unit m_die_array data into each of its parent
DW_TAG_compile_unit as it may be a performance hit.

But then I am not sure whether it is worth it - when LLDB does fully populate
m_die_array?  Currently it always has to as on non-OSX platforms it is using
DWARFCompileUnit::Index(). But as I plan to implement DWARF-5 .debug_names
index (like __apple_* index) maybe LLDB then no longer needs to populate
m_die_array and so just expanding all DW_TAG_partial_unit into a single
m_die_array for each DW_TAG_compile_unit is fine?

Thanks for info,
Jan Kratochvil

More information about the lldb-dev mailing list