[Lldb-commits] [PATCH] D63005: DWARF: Don't create lldb CompileUnits for DWARF type units

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Jun 7 04:30:51 PDT 2019

labath created this revision.
labath added reviewers: clayborg, JDevlieghere, aprantl.
Herald added a subscriber: jdoerfert.
labath added a parent revision: D62894: DWARF: Share line tables of type units.

Type units don't represent actual compilations and a lot of the
operations that we do with lldb compile units (getting their line
tables, variables, etc.) don't make sense for them. There is also a lot
more of them (sometimes over 100x), so making them more lightweight pays

The main change in this patch is that we stop creating lldb CompileUnits
for DWARF type units. The trickiest part here is that the SymbolFile
interface requires that we assign consecutive sequence IDs to the
compile units we create. As DWARF type and compile units can come in any
order (in v5), this means we can no longer use 1-1 mapping between DWARF
and lldb compile units. Instead I build a translation table between the
two indices. To avoid pessimizing the case where there are no type
units, I build the translation table only in case we have at least one
type unit.

Additionaly, I also tried to strenghted type safete by replacing
DWARFUnit with DWARFCompileUnit where applicable. Though that was not
stricly necessary, I found it a good way to ensure that the
transformations I am doing here make sense. In the places where I was
changing the function signatures, and where it was obvious that the
objects being handled were not null, I also replaced pointers with

There shouldn't be any major functional change with this patch. The only
change I observed is that now the types in the type units will not be
parsed when one calls Module::ParseAllDebugSymbols, unless they are
referenced from other compile units. This makes sense, given how
ParseAllDebugSymbols is implemented (it iterates over all compile
units), and it only matters for one hand-writted test where I did not
bother to reference the types from the compile units (which I now do).



-------------- next part --------------
A non-text attachment was scrubbed...
Name: D63005.203534.patch
Type: text/x-patch
Size: 35364 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20190607/88dcdddd/attachment-0001.bin>

More information about the lldb-commits mailing list