[Lldb-commits] [PATCH] D73206: Pass `CompileUnit *` along `DWARFDIE` for DWZ
Jan Kratochvil via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Wed Mar 18 08:08:55 PDT 2020
jankratochvil added a comment.
In D73206#1928869 <https://reviews.llvm.org/D73206#1928869>, @labath wrote:
> But I'm not sure that removing `GetBaseSymbolFile` is the right way to start that, as without it you cannot implement the redirection.
Current code is:
SymbolFileDWARF::DIEToTypePtr &SymbolFileDWARFDwo::GetDIEToType() { return GetBaseSymbolFile().GetDIEToType(); }
typedef llvm::DenseMap<const DWARFDebugInfoEntry *, lldb_private::Type *> DIEToTypePtr;
There will need to be the following change for DWZ anyway - as the same `DWARFDebugInfoEntry *` can lead to different `Types` depending on its Main CU:
typedef llvm::DenseMap<std::pair<DWARFUnit *, const DWARFDebugInfoEntry *>, lldb_private::Type *> DIEToTypePtr;
Where the `pair.first` would be `DWARFUnit *main_cu` for DWZ. And so then the `SymbolFileDWARFDwo` redirection can be done from that `main_cu` pointer (with some interface refactorization).
> Where are you going with that question? If it's stopping you from doing anything, I can try to look into that a bit closer...
As I have currently some difficulties unifying the DWZ MainCU tracking with DWO MainCU tracking. DWZ deals only with `DW_TAG_compile_unit` and not with `DW_TAG_type_unit` as DWZ can unify+reference types more effectively using `DW_FORM_ref*`. While DWO deals also with `DWARFTypeUnit`. Each DWZ `DWARFCompileUnit` has corresponding `CompileUnit` but `DWARFTypeUnit` does not have any. So in `SymbolFileDWARF::GetTypeForDIE` for DWO it will use the second code path:
SymbolContextScope *scope;
if (auto *dwarf_cu = llvm::dyn_cast<DWARFCompileUnit>(die.GetCU()))
scope = GetCompUnitForDWARFCompUnit(*dwarf_cu);
else
scope = GetObjectFile()->GetModule().get();
Therefore this code of mine no longer works as `comp_unit==nullptr` for `DWARFTypeUnit`s:
DWARFUnit *main_unit = dwarf->GetDWARFCompileUnit(sc.comp_unit);
So either I would need to add new tracking `DWARFUnit *main_unit` even to functions which already have `SymbolContext &sc` parameter. Or more probably I need to somehow track the skeleton file some other way (looking it up from `sc.module_sp` by its hash?).
Without DWO support it is easier as I no longer have to work on the DWO MainCU tracking which is a task of its own. Also I could use the type `DWARFCompileUnit *main_unit` which saves some downcastings.
So I am asking if the DWO support together with DWZ brings some real improvements as it complicates the situation for the DWZ support.
Just for illustration: https://people.redhat.com/jkratoch/lldb-main_unit-DWARFUnit.patch or the non-DWO start of simplification: https://people.redhat.com/jkratoch/lldb-main_unit-DWARFCompileUnit.patch
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D73206/new/
https://reviews.llvm.org/D73206
More information about the lldb-commits
mailing list