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

Jan Kratochvil via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Wed Nov 29 14:04:06 PST 2017

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.


More information about the lldb-commits mailing list