This is the second dwp preparatory patch. When a SymbolFileDWARFDwo will
hold more than one split unit, it will not be able to be uniquely owned
by a single DWARFUnit. I achieve this by changing the
unique_ptr<SymbolFileDWARFDwo> member of DWARFUnit to
shared_ptr<DWARFUnit>. The shared_ptr points to a DWARFUnit, but it is
in fact holding the entire SymbolFileDWARFDwo alive. This is the same
method used by llvm DWARFUnit (except that is uses the DWARFContext
class).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp | ||
---|---|---|
56 | How often does this function get called? Should we cache the DW_AT_GNU_dwo_id in the DWARFCompileUnit to avoid extracting the DW_AT_GNU_dwo_id attribute maybe multiple times? | |
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h | ||
67 | Curious: what is a single compile unit? A bit of a comment in header doc here might be nice. |
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp | ||
---|---|---|
56 | In a dwo file, this function will be called exactly once. With a DWP file (the next patch) it will get called once for each compile unit, but it will return a different compile unit each time, so for a single compile unit, the dwo_id attribute will still be accessed only once. | |
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h | ||
67 | I've added a simple comment. The idea is that a dwo file will normally(*) contain exactly one compile unit. This function will find it and return it. (*) This may not be 100% as I believe llvm can produce multiple CUs in a dwo file under some circumstances, but I'm not sure if this is fully conforming, and it is definitely not something that works in lldb right now. |
Curious: what is a single compile unit? A bit of a comment in header doc here might be nice.