This is an archive of the discontinued LLVM Phabricator instance.

[DWARF] Align non-accelerated function fullname searching with the apple-tables path
ClosedPublic

Authored by labath on May 8 2018, 4:59 AM.

Details

Summary

Before this patch the two paths were doing very different things

  • the apple path searched the .apple_names section, which contained mangled names, as well as basenames of all functions. It returned any name it found.
  • the non-accelerated path looked in the "full name" index we built ourselves, which contained mangled as well as demangled names of all functions (but no basenames). Then however, if it did not find a match it did an extra search in the basename index, with some special handling for anonymous namespaces.

This aligns the two paths by changing the non-accelerated path to return
the same results as in the apple-tables one. In pratice, this means we
will search in both the "basename" and "method" indexes (in the manual
indexes we keep methods separately). This means the function will return
some slightly inappropriate results (e.g. bar::baz::foo when one asks
for a "full name" foo), but this can be handled by additional filtering,
independently indexing method. To make this work, I've also started
inserting mangled names into the manual "basename" index.

I've also stopped matching demangled names when a regex search is
requested as that is not what apple tables do.

After this change the manual "fullname" is unused and can be removed.

Event Timeline

labath created this revision.May 8 2018, 4:59 AM
JDevlieghere accepted this revision.May 8 2018, 5:33 AM
This revision is now accepted and ready to land.May 8 2018, 5:33 AM

See inlined comments

source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
901–902

Why are we adding the mangled name to the basenames?

905–908

Should we remove these 4 lines now? I thought we weren't going to add demangled names to the index?

928–929

Why are we adding the mangled name to the basenames?

labath added inline comments.May 8 2018, 9:26 AM
source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
905–908

I was saving that for a separate patch.

928–929

It was the simplest way to ensure we get the same results for apple and !apple cases. With apple tables we will return a result if someone asks for a function with a "base name" _Z3foov. I am not sure if this was intended or just an accident. Alternatively, I could keep these names in a separate index and then search in both when I get a query. Or, if this is really not intended to work, I can adding extra filtering to the "apple" path to return only "real" basenames. (My goal here is to eliminate platform differences to avoid things behaving differently across platforms.)

clayborg added inline comments.May 8 2018, 9:30 AM
source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
928–929

I would search "func_fullnames" and "func_basenames" separately and avoid adding the extra mangled name to func_basenames.

The _Z3foov seems like an accident. It definitely shouldn't be a basename unless the DWARF put that into the DW_AT_name field for some reason.

labath updated this revision to Diff 145717.May 8 2018, 10:07 AM

Stopped inserting demangled names into the fullname index and made the
FindFunctions index search in all three indices (fullname, basename, method).
The last two shouldn't really contain full names, but they seem to be required
for the correct operation (and they match what the apple path does).

clayborg accepted this revision.May 8 2018, 10:08 AM

Much better.

Before adding the DWARF 5 index support, we should virtualize this searching and indexing into a base class. Then we make 1 class for manual DWARF indexing, one for Apple indexes, and one for DWARF5. Then we can unit test each one easily. Thoughts?

the class would be something like:

class DWARFIndex {

virtual bool Initialize(SymbolFileDWARF &dwarf); // Do manual indexing, or load indexes. Return true if successful (found apple tables, DWARF 5 tables, or had debug info to manually index)
virtual ... Lookup(ConstString name, type, etc);

};

Before adding the DWARF 5 index support, we should virtualize this searching and indexing into a base class. Then we make 1 class for manual DWARF indexing, one for Apple indexes, and one for DWARF5. Then we can unit test each one easily. Thoughts?

Yes, that's exactly where I'm heading. I started doing that, but then I noticed that two of the existing paths were sometimes very different for no apparent reason. I'm trying to bring them closer together to make the interface of the index class saner.

This revision was automatically updated to reflect the committed changes.