[Lldb-commits] [PATCH] D40466: DWZ 03/12: DWARFCompileUnit split to DWARFCompileUnitData

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil marked an inline comment as done.
jankratochvil added inline comments.


================
Comment at: source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h:216
 
+  DWARFCompileUnitData *m_data;
+
----------------
clayborg wrote:
> jankratochvil wrote:
> > clayborg wrote:
> > > Is there a reason this is a member variable that I am not seeing? Seems we could have this class inherit from DWARFCompileUnitData. I am guessing this will be needed for a future patch?
> > Yes, future patch D40474 contains a new constructor so multiple `DWARFCompileUnit` then point to single `DWARFCompileUnitData`.  Sure that happens only in the case ot `DW_TAG_partial_unit` (one `DWARFCompileUnit` is read from a file while other `DWARFCompileUnit` are remapped instances with unique offset as used from units which did use `DW_TAG_imported_unit` for them).
> > `DWARFCompileUnit(DWARFCompileUnitData *data, DWARFCompileUnit *main_cu);`
> > 
> We should just have an instance of this in this class and add a virtual function to retrieve it. Then we make a DWARFPartialUnit that subclasses this and has its own extra member variable and can use either one when it makes sense. Not a fan of just having a dangling pointer with no clear ownership. There is no "delete m_data" anywhere?
The `DWARFCompileUnitData *m_data` content is being held in: `std::forward_list<DWARFCompileUnitData> SymbolFileDWARF::m_compile_unit_data_list` as I hope/believe a `DWARFCompileUnit` is never deleted until whole `SymbolFileDWARF` is deleted.  I did not use `std::shared_ptr<DWARFCompileUnitData> DWARFCompileUnit::m_data` as `shared_ptr` is both memory and lock-instruction-performance expensive.



https://reviews.llvm.org/D40466