Page MenuHomePhabricator

[DWARF] Extract indexing code into a separate class hierarchy
ClosedPublic

Authored by labath on May 15 2018, 9:20 AM.

Details

Summary

This places the if(m_using_apple_tables) branches inside the
SymbolFileDWARF class behind an abstract DWARFIndex class. The class
currently has two implementations:

  • AppleIndex, which searches using .apple_names and friends
  • ManualIndex, which searches using a manually built index

Most of the methods of the class are very simple, and simply extract the
list of DIEs for the given name from the appropriate sub-table. The main
exception are the two GetFunctions overloads, which take a couple of
extra paramenters, including some callbacks. It was not possible to
split these up the same way as other methods, as here we were doing a
lot of post-processing on the results. The post-processing is similar
for the two cases, but not identical. I hope to factor these further in
separate patches.

Other interesting methods are:

  • Preload(): do any preprocessing to make lookups faster (noop for AppleIndex, forces a build of the lookup tables for ManualIndex).
  • ReportInvalidDIEOffset(): Used to notify the users of an invalid index (prints a message for AppleIndex, noop for ManualIndex).
  • Dump(): dumps the index state (noop for AppleIndex, prints the lookup tables for ManualIndex).

Diff Detail

Repository
rL LLVM

Event Timeline

labath created this revision.May 15 2018, 9:20 AM

Looks good to me, but I'll defer to Greg as I've never actually touched this code myself.

Looks fine. Just one question on keeping the DWARFIndex::Create() functions so they all have the same signature.

source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
40 ↗(On Diff #146853)

Move all AppleIndex stuff to a dedicated .cpp file?

321 ↗(On Diff #146853)

Move all ManualIndex stuff to a dedicated .cpp file?

source/Plugins/SymbolFile/DWARF/DWARFIndex.h
71 ↗(On Diff #146853)

Rename to AppleDWARFIndex and move to AppleDWARFIndex.h?

127 ↗(On Diff #146853)

Rename to ManualDWARFIndex and move to ManualDWARFIndex.h?

clayborg added inline comments.May 17 2018, 7:15 AM
source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
40 ↗(On Diff #146853)

Do we want all DWARFIndex::Create(...) signatures to take a SymbolFileDWARF only? Then module can be extracted from that and all sections can be fetched as well?

Thank you for the review. I'll have the updated diff shortly. In the mean time, here are my responses.

source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp
40 ↗(On Diff #146853)

SymbolFileDWARF does not provide public accessors for individual sections. I would have to make LoadSectionData or some other get-me-a-section api available. I like how this is explicit about what kind of data a particular accelerator table depends on.

source/Plugins/SymbolFile/DWARF/DWARFIndex.h
71 ↗(On Diff #146853)

The classes seemed small enough to keep in one file, but that works for me too. A more canonical name here would be DWARFAppleIndex.h, but i hate how everything in this folder begins with DWARF, so this is a place I'll happily diverge from the norm. :P

labath updated this revision to Diff 147326.May 17 2018, 8:19 AM
  • s/AppleIndex/AppleDWARFIndex
  • move things to separate files
clayborg accepted this revision.May 17 2018, 8:35 AM
clayborg added inline comments.
source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
1984 ↗(On Diff #147326)

Yikes, who was calling PreloadSymbols before? Was this causing all Apple systems to manually index the DWARF as well??? That is bad. Fix now with you changes to the right, but scary.

This revision is now accepted and ready to land.May 17 2018, 8:35 AM
This revision was automatically updated to reflect the committed changes.

This caused a failure in green dragon: http://green.lab.llvm.org/green/job/lldb-xcode/6644

Can you please fix or revert this change, thanks.

aemerson reopened this revision.May 18 2018, 9:04 AM

Hi Pavel,

I reverted this in r332730 due to the bot breaking. Please have a look and commit again when ready.

Thanks,
Amara

This revision is now accepted and ready to land.May 18 2018, 9:04 AM

Thanks for jumping on this Amara — I just wanted to point out that we ususally don't revert lldb changes that only break the lldb-xcode bot if they pass on the lldb-cmake bot at the same time. When this happens it usually means that the lldb Xcode project must be updated and it's too much to ask from all open source contributors to get access to a machine running Xcode to do this. Instead one of the Apple LLDB developers usually goes in and updates the Xcode project for them.

  • adrian

Thanks for jumping on this Amara — I just wanted to point out that we ususally don't revert lldb changes that only break the lldb-xcode bot if they pass on the lldb-cmake bot at the same time. When this happens it usually means that the lldb Xcode project must be updated and it's too much to ask from all open source contributors to get access to a machine running Xcode to do this. Instead one of the Apple LLDB developers usually goes in and updates the Xcode project for them.

  • adrian

Ah ok. Does that include cases like this one with the link error:

Undefined symbols for architecture x86_64:
  "lldb_private::AppleDWARFIndex::Create(lldb_private::Module&, lldb_private::DWARFDataExtractor, lldb_private::DWARFDataExtractor, lldb_private::DWARFDataExtractor, lldb_private::DWARFDataExtractor, lldb_private::DWARFDataExtractor)", referenced from:
      SymbolFileDWARF::InitializeObject() in liblldb-core.a(SymbolFileDWARF.o)
  "vtable for lldb_private::ManualDWARFIndex", referenced from:
      SymbolFileDWARF::InitializeObject() in liblldb-core.a(SymbolFileDWARF.o)
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.

Thanks for jumping on this Amara — I just wanted to point out that we ususally don't revert lldb changes that only break the lldb-xcode bot if they pass on the lldb-cmake bot at the same time. When this happens it usually means that the lldb Xcode project must be updated and it's too much to ask from all open source contributors to get access to a machine running Xcode to do this. Instead one of the Apple LLDB developers usually goes in and updates the Xcode project for them.

  • adrian

Ah ok. Does that include cases like this one with the link error:

Undefined symbols for architecture x86_64:
  "lldb_private::AppleDWARFIndex::Create(lldb_private::Module&, lldb_private::DWARFDataExtractor, lldb_private::DWARFDataExtractor, lldb_private::DWARFDataExtractor, lldb_private::DWARFDataExtractor, lldb_private::DWARFDataExtractor)", referenced from:
      SymbolFileDWARF::InitializeObject() in liblldb-core.a(SymbolFileDWARF.o)
  "vtable for lldb_private::ManualDWARFIndex", referenced from:
      SymbolFileDWARF::InitializeObject() in liblldb-core.a(SymbolFileDWARF.o)
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.

A link error is the most common manifestation of a file not being added to the xcode project. the vtable in question would have been emitted if ManualDWARFIndex.cpp (created by this CL) was built with everything else.

I did verify that this patch builds (with cmake) and all tests pass on darwin, so I don't expect there to be any other problems.

I am going to try relanding this when I'm back at work on Monday, but until then, if someone knows how to add these files to the project, I'd appreciate it if he can submit those changes together with this patch, and we can avoid having the bot go red again.

labath closed this revision.Jul 19 2018, 6:46 AM