[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