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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
