Summary:
This patch adds the ability to lookup variables to the DWARF v5 index
class.
During review we discovered an inconsistency between how the existing
two indexes handle looking up qualified names of the variables:
- manual index would return a value if the input string exactly matched
the demangled name of some variable.
- apple index ignored the context and returned any variable with the
same base name.
So, this patch also rectifies that situation:
- it removes all context handling from the index classes. The
GetGlobalVariables functions now just take a base name. For manual
index, this meant we can stop putting demangled names into the
variable index (this matches the behavior for functions).
- context extraction is put into SymbolFileDWARF, so that it is common
to all indexes.
- additional filtering based on the context is also done in
SymbolFileDWARF. This is done via a simple substring search, which is
not ideal, but it matches what we are doing for functions (cf.
Module::LookupInfo::Prune).
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47781
llvm-svn: 334181
Summary:
Now that we are able to parse MachO files everywhere, we can write some
cross-platform tests for handling of apple accelerator tables. This
reruns the same lookup tests we have for manual indexes on MachO files
which will use the accelerator tables instead. This makes sure we return
the same results regardless of the method we used to access the debug
info.
The tests confirm we return the same results for looking up types,
namespaces and variables, but have found an inconsistency in the
treatment of function lookup. In the function case we mis-classify the
method "foo" declared in the local struct sbar (inside function ffbar).
We classify it as a function whereas it really is a method. Preliminary
analysis suggests this is because
DWARFASTParserClang::GetClangDeclContextForDIE returns null when given
the local "struct sbar" DIE. This causes us to get the wrong
CompilerDeclContext when we ask for the context of the inner foo, which
means CompilerDeclContext::ISStructUnionOrClass returns false.
Until this is fixed, I do not include the darwin versions of the "base"
and "method" function lookup tests.
Reviewers: JDevlieghere, clayborg
Subscribers: aprantl, ilya-biryukov, ioeric, lldb-commits
Differential Revision: https://reviews.llvm.org/D47064
llvm-svn: 332831
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
Pavel Labath