[Lldb-commits] [PATCH] D45170: Cleanup DWARFCompileUnit and DWARFUnit in preparation for adding DWARFTypeUnit

Jan Kratochvil via lldb-commits lldb-commits at lists.llvm.org
Wed Apr 11 04:46:29 PDT 2018


On Wed, 11 Apr 2018 01:24:53 +0200, Jan Kratochvil wrote:
> On Wed, 11 Apr 2018 00:53:20 +0200, Jan Kratochvil wrote:
> > On Wed, 11 Apr 2018 00:22:45 +0200, Greg Clayton wrote:
> > > If this is all in the same file, then the offsets are all in the
> > > .debug_info? What am I missing?
> > 
> > LLVM was asserting when I reported the same lldb::user_id_t referenced by
> > multiple CUs. From our discussion it looks to me that maybe I just did not
> > have the DWZ common symbol file with proper offset. Otherwise maybe I can
> > report the same lldb::user_id_t if multiple CUs reference the same DIE from
> > DW_TAG_partial_unit? As LLVM considers all CUs in a file as the same context.
> > I will try that again.
> 
> In such case if you are sure no real DIEs remapping (to make each inclusion of
> DW_TAG_partial_unit unique) is needed then no remapping DWARFPartialUnit is
> needed and your removal of my DWARFUnit abstraction by Data() (which
> I incorrectly reverted) is also OK.
> 
> (Although I will believe it only after I code it; this is what I coded first
> but I could have some other bugs there that time.)

I have found that the assertions happened at least due to
SymbolFileDWARF::GetTypeForDIE() which finds a function for the DIE from
DW_AT_partial_unit which is then missing or different than the expected one.
It then asserts somewhere in clang that the context is unexpected.

The problem with non-unique DW_AT_partial_unit DIEs is that
DWARFDebugInfoEntry::GetParent() cannot work for them but LLDB does depend on
that method.

If you think it is workaroundable I can get deeper into it but this is why I
decided each effective (=imported) DIE should have its unique lldb::user_id_t.


Thanks,
Jan


I had in my old notes some such dump:

#0  DWARFCompileUnit::GetDIE (this=0x611000024f80, die_offset=139)
    at tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:571
#1  0x00007fffe2faea83 in DWARFDebugInfo::GetDIE (this=0x607000013ff0, die_ref=...)
    at tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp:274
#2  0x00007fffe300a89c in SymbolFileDWARF::GetDIE (this=0x61d000008c80, die_ref=...)
    at tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1573
#3  0x00007fffe301d581 in SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext (this=0x61d000008c80, dwarf_decl_ctx=...)
    at tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:3458
#4  0x00007fffe2ef936f in DWARFASTParserClang::ParseTypeFromDWARF (this=0x610000004d40, sc=..., die=..., log=0x0, type_is_new_ptr=0x0)
    at tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:727
#5  0x00007fffe301e243 in SymbolFileDWARF::ParseType (this=0x61d000008c80, sc=..., die=..., type_is_new_ptr=0x0)
    at tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:3563
#6  0x00007fffe301b054 in SymbolFileDWARF::GetTypeForDIE (this=0x61d000008c80, die=..., resolve_function_context=false)
    at tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:3106
#7  0x00007fffe3009bfd in SymbolFileDWARF::ResolveType (this=0x61d000008c80, die=..., assert_not_being_parsed=true,
    resolve_function_context=false)


More information about the lldb-commits mailing list