Page MenuHomePhabricator

DWARF: Don't create lldb CompileUnits for DWARF type units

Authored by labath on Jun 7 2019, 4:26 AM.



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).

Diff Detail


Event Timeline

labath created this revision.Jun 7 2019, 4:26 AM
clayborg accepted this revision.Jun 7 2019, 9:24 AM
This revision is now accepted and ready to land.Jun 7 2019, 9:24 AM
aprantl added inline comments.Jun 7 2019, 2:18 PM
726 ↗(On Diff #203534)
if (!info) 
  return {};


labath updated this revision to Diff 203816.Jun 10 2019, 7:19 AM
  • account for the fact that D62943 was a dud. Instead, set the correct ID of the compile unit so that the DWARF unit can be found via the regular logic.
  • add a test for the situation where the dwarf and lldb compile unit indexes do not match
labath updated this revision to Diff 203820.Jun 10 2019, 7:23 AM
  • Also implement Adrians suggestion.
JDevlieghere accepted this revision.Jun 10 2019, 9:11 AM

I saw some weird formatting, but I assume you run clang-format before landing anyway. LGTM.

I saw some weird formatting, but I assume you run clang-format before landing anyway. LGTM.

Actually, I usually use it interactively while editing, and then do a final pass before creating the diff. However, it looks like I missed it this time. :) I have reformatted my local copy now.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJun 13 2019, 4:20 AM