[Lldb-commits] [PATCH] D62395: WIP: Dont vend lldb_private::CompileUnits for DWARFTypeUnits

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: clayborg, JDevlieghere, aprantl, jingham.
Herald added a subscriber: jdoerfert.

This patch isn't meant to be committed, but it is here to demostrate
what it would take to implement the idea proposed by Greg in
D62073#1507063 <https://reviews.llvm.org/D62073#1507063>.

The background here is that a type unit build will have substantially
more "units" than a regular one (e.g., a type unit build of lldb will
have about 1k compile units, but almost 400k type units). Vending them
all as lldb_private::CompileUnits is a bit wasteful. It can be made less
wasteful by making sure the CompileUnits share line tables and stuff
(just like DWARF units do), but it's not clear to me whether this is
really useful/needed. For instance, lldb CompileUnits expect to have a
"name" (a file path), but type units don't have that as they're supposed
to be independent/shared between real compile units.

The majority of changes here just deal with the remapping of dwarf vs.
lldb unit indexes, as now we can now no longer use a 1:1 mapping.
However, there are a couple of things that are worth calling out
explicitly:

- DWARFASTParserClang goes through the lldb CompileUnits in order to fetch file names. Right now I've just deleted that code. In a proper solution, we'd need to find a way to get this information strictly through DWARF structures.
- The main visible side effect I can see from this is that we will stop filling out the SymbolContextScope field https://lldb.llvm.org/cpp_reference/classlldb__private_1_1Type.html#aea1b2a6336880f67455036803bf42ea1 of the Type objects that we hand about. More precisely, we can still fill out the "module" part, but not the "compile unit". I'm not sure what are the implications of that, but maybe that is even more correct as the type unit does not really belong to any single compilation. This patch breaks just three tests, and all of them seem related to me stopping to parse the file names, and not this...

So, does anyone see why (a cleaned up version of) this would be a bad
idea?


https://reviews.llvm.org/D62395

Files:
  source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
  source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.cpp
  source/Plugins/SymbolFile/DWARF/DWARFDebugInfo.h
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D62395.201246.patch
Type: text/x-patch
Size: 16073 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20190524/1c48d7f5/attachment-0001.bin>