Page MenuHomePhabricator

[lldb/DWARF] Don't assume that a SymbolFileDWARFDwo contains one compile unit

Authored by labath on Jan 31 2020, 6:08 AM.



This is a preparatory patch to re-enable DWP support in lldb (we already
have code claiming to do that, but it has been completely broken for a
while now).

The idea of the new approach is to make the SymbolFileDWARFDwo class
handle both dwo and dwo files, similar to how llvm uses one DWARFContext
to handle the two.

The first step is to remove the assumption that a SymbolFileDWARFDwo
holds just a single compile unit, i.e. the GetBaseCompileUnit method.
This requires changing the way how we reach the skeleton compile unit
(and the lldb_private::CompileUnit) from a dwo unit, which was
previously done via GetSymbolFile()->GetBaseCompileUnit() (and some
virtual dispatch).

The new approach reuses the "user data" mechanism of DWARFUnits, which
was used to link dwarf units (both skeleton and split) to their
lldb_private counterparts. Now, this is done only for non-dwo units, and
instead of that, the dwo units holds a pointer to the relevant skeleton

Diff Detail

Event Timeline

labath created this revision.Jan 31 2020, 6:08 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 31 2020, 6:08 AM
Herald added a subscriber: arphaman. · View Herald Transcript
JDevlieghere accepted this revision.Jan 31 2020, 9:54 AM

DWO is not really my area of expertise but this looks pretty straightforward.


Did you forget to clang-format?

This revision is now accepted and ready to land.Jan 31 2020, 9:54 AM
clayborg accepted this revision.Jan 31 2020, 10:26 AM
labath marked 2 inline comments as done.Feb 5 2020, 8:37 PM
labath added inline comments.

Nope, this is already clang-formatted.

This revision was automatically updated to reflect the committed changes.
labath marked an inline comment as done.
JDevlieghere added inline comments.Feb 5 2020, 9:44 PM

We must be using a different version then :-)