[Lldb-commits] [PATCH] D73206: Pass `CompileUnit *` along `DWARFDIE` for DWZ

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D73206#1928710 <https://reviews.llvm.org/D73206#1928710>, @jankratochvil wrote:

> In D73206#1871895 <https://reviews.llvm.org/D73206#1871895>, @labath wrote:
>
> > Yep. It may be interesting to try this out on regular dwo first. Right now, dwo dodges this problem by storing a CompileUnit pointer on both skeleton and split units. If we can make this work without the split unit back pointer, then we can come move closer to how things work in llvm, and also pave the way for the dwz stuff.
>
>
> Just clarifying if you would therefore like to remove these two items:
>
>   SymbolFileDWARF &SymbolFileDWARFDwo::GetBaseSymbolFile() { return m_base_symbol_file; }
>   SymbolFileDWARF &SymbolFileDWARFDwo::m_base_symbol_file;
>   


Eventually I'd like to delete the entire `SymbolFileDWARFDwo` class. Right now, it serves almost no useful purpose -- nearly all of its methods just redirect to the "base" symbol file in interesting (and confusing) ways. But I'm not sure that removing `GetBaseSymbolFile` is the right way to start that, as without it you cannot implement the redirection.

The way I was considering doing this was first ensuring that all other objects which store a SymbolFileDWARF pointer are updated to point to the "base" object. But there are probably even other things that need to be done before that, such as moving the lower-level dwarf stuff from SymbolFileDWARF to DWARFContext. Then the "base" DWARFContext could be directly responsible for creating "dwo" DWARFContexts (just like it is in llvm) and SymbolFileDWARFDwo could be removed. I am not sure how much work all of that is though...

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...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73206/new/

https://reviews.llvm.org/D73206