When moving the GetTypeForDIE function from DWARFASTParserClang to
DWARFASTParser, I kept the signature as-is. To match the rest of the
function signatures in DWARFASTParser, remove the full name
(lldb_private::plugin::dwarf::DWARFDIE -> DWARFDIE) in the signature of
DWARFASTParser::GetTypeForDIE.
As a followup of https://github.com/llvm/llvm-project/pull/67851, I'm
defining a new namespace `lldb_plugin::dwarf` for the classes in this
Plugins/SymbolFile/DWARF folder. This change is very NFC and helped me
with exporting the necessary symbols for my out-of-tree language plugin.
The only class that I didn't change is ClangDWARFASTParser, because that
shouldn't be in the same namespace as the generic language-agnostic
dwarf parser.
It would be a good idea if other plugins follow the same namespace
scheme.
Without checking template parameters, we would sometimes lookup the
wrong type definition for a type declaration because different
instantiations of the same template class had the same debug info name.
The added GetForwardDeclarationDIETemplateParams() shouldn't need a
cache because we'll cache the results of the declaration -> definition
lookup anyway. (DWARFASTParserClang::ParseStructureLikeDIE()
is_forward_declaration branch)
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D138834
This reverts commit 967df65a3610f98a3bc0ec0f2303641d7bad176c.
This fixes test/Shell/SymbolFile/NativePDB/find-functions.cpp. When
looking up functions with the PDB plugins, if we are looking for a
full function name, we should use `GetName` to populate the `name`
field instead of `GetLookupName` since `GetName` has the more
complete information.
This reverts commit befa77e59a7760d8c4fdd177b234e4a59500f61c.
Looks like this broke a SymbolFileNativePDB test. I'll investigate and
resubmit with a fix soon.
Context:
When setting a breakpoint by name, we invoke Module::FindFunctions to
find the function(s) in question. However, we use a Module::LookupInfo
to first process the user-provided name and figure out exactly what
we're looking for. When we actually perform the function lookup, we
search for the basename. After performing the search, we then filter out
the results using Module::LookupInfo::Prune. For example, given
a:🅱️:foo we would first search for all instances of foo and then filter
out the results to just names that have a:🅱️:foo in them. As one can
imagine, this involves a lot of debug info processing that we do not
necessarily need to be doing. Instead of doing one large post-processing
step after finding each instance of `foo`, we can filter them as we go
to save time.
Some numbers:
Debugging LLDB and placing a breakpoint on
llvm::itanium_demangle::StringView::begin without this change takes
approximately 70 seconds and resolves 31,920 DIEs. With this change,
placing the breakpoint takes around 30 seconds and resolves 8 DIEs.
Differential Revision: https://reviews.llvm.org/D129682
This patch renames DW_ACCESS_to_AccessType function and move it to the abstract
DWARFASTParser, since there is no clang-specific code there. This is useful for
plugins other than Clang.
Reviewed By: shafik, bulbazord
Differential Revision: https://reviews.llvm.org/D114719
Front-load the first_valid_code_address check, so that we avoid creating
the function object (instead of simply refusing to use it in queries).
Differential Revision: https://reviews.llvm.org/D112310
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.
Differential revision: https://reviews.llvm.org/D74743
Split out the logic to parse structure-like types into a separate
function, in an attempt to reduce the complexity of ParseTypeFromDWARF.
Inspired by discussion in https://reviews.llvm.org/D68130.
Differential Revision: https://reviews.llvm.org/D68422
llvm-svn: 373927
This implements
DWARFASTParserClang::EnsureAllDIEsInDeclContextHaveBeenParsed so as to
provide a faster way to ensure all DIEs linked to a certain declaration
context have been parsed.
Currently, we rely on SymbolFileDWARF::ParseDeclsForContext calling
DWARFASTParserClang::GetDIEForDeclContext, and only then
DWARFASTParserClang::GetDeclForUIDFromDWARF. This change shortcuts that
logic and removes redundant calls to DWARFASTParserClang::
GetClangDeclForDIE by deleting DIEs from the m_decl_ctx_to_die map once
they have been parsed.
Differential Revision: https://reviews.llvm.org/D67760
Patch by Guilherme Andrade <guiandrade@google.com>.
llvm-svn: 372744
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Previously all of these functions accepted a SymbolContext&.
While a CompileUnit is one member of a SymbolContext, there
are also many others, and by passing such a monolithic parameter
in this way it makes the requirements and assumptions of the
API unclear for both callers as well as implementors.
All these methods need is a CompileUnit. By limiting the
parameter type in this way, we simplify the code as well as
make it self-documenting for both implementers and users.
Differential Revision: https://reviews.llvm.org/D56564
llvm-svn: 350943
Clang recently improved its DWARF support for C VLA types. The DWARF
now looks like this:
0x00000051: DW_TAG_variable [4]
DW_AT_location( fbreg -32 )
DW_AT_name( "__vla_expr" )
DW_AT_type( {0x000000d3} ( long unsigned int ) )
DW_AT_artificial( true )
...
0x000000da: DW_TAG_array_type [10] *
DW_AT_type( {0x000000cc} ( int ) )
0x000000df: DW_TAG_subrange_type [11]
DW_AT_type( {0x000000e9} ( __ARRAY_SIZE_TYPE__ ) )
DW_AT_count( {0x00000051} )
Without this patch LLDB will naively interpret the DIE offset 0x51 as
the static size of the array, which is clearly wrong. This patch
extends ValueObject::GetNumChildren to query the dynamic properties of
incomplete array types.
See the testcase for an example:
4 int foo(int a) {
5 int vla[a];
6 for (int i = 0; i < a; ++i)
7 vla[i] = i;
8
-> 9 pause(); // break here
10 return vla[a-1];
11 }
(lldb) fr v vla
(int []) vla = ([0] = 0, [1] = 1, [2] = 2, [3] = 3)
(lldb) quit
rdar://problem/21814005
Differential Revision: https://reviews.llvm.org/D53530
llvm-svn: 346165
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
This allows these functions to be re-used by a forthcoming
PDBASTParser. The functions in question are CanCompleteType,
CompleteType, and CanImport. Conceptually, these functions belong
on ClangASTImporter anyway, and previously they were just ping
ponging around through a few levels of indirection to end up there
as well, so this patch actually makes the code somewhat simpler.
A few methods were moved to a new file called ClangUtil, so that
they can be shared between ClangASTImporter and ClangASTContext
without creating a circular dependency between those two cpp
files.
Differential Revision: http://reviews.llvm.org/D18381
llvm-svn: 264685
It was previously reverted due to issues that showed up only on linux. I was able to reproduce these issues and fix the underlying cause.
So this is the same patch as 254476 with the following two fixes:
- Fix not trying to complete classes that don't have external sources
- Fix ClangASTSource::CompleteType() to check the decl context of types that it finds by basename to ensure we don't complete a type "S" with a type like "std::S". Before this fix ClangASTSource::CompleteType() would accept _any_ type that had a matching basename and copy it into the other type.
<rdar://problem/22992457>
llvm-svn: 254980
This is done by finding the types that are forward declarations that come from a module, and loading that module's debug info in a separate lldb_private::Module, and copying the type over into the current module using a ClangASTImporter object. ClangASTImporter objects are already used to copy types from on clang::ASTContext to another for expressions so the type copying code has been around for a while.
A new FindTypes variant was added to SymbolVendor and SymbolFile:
size_t
SymbolVendor::FindTypes (const std::vector<CompilerContext> &context, bool append, TypeMap& types);
size_t
SymbolVendor::FindTypes (const std::vector<CompilerContext> &context, bool append, TypeMap& types);
The CompilerContext is a way to represent the exact context of a type and pass it through an agnostic API boundary so that we can find that exact context elsewhere in another file. This was required here because we can have a module that has submodules, both of which have a "foo" type.
I am not able to add tests for this yet as we currently don't build our C/C++/ObjC binaries with the clang binary that we build. There are some driver issues where it can't find the header files for the C and C++ standard library which makes compiling these tests hard. We can't also guarantee that if we are building with clang that it supporst the exact format of -gmodule debugging that we are trying to test. We have had other versions of clang that had a different implementation of -gmodule debugging that we are no longer supporting, so we can't enable tests if we are building with clang without compiling something and looking at the structure of the DWARF that was generated to ensure that it is the format we can actually use.
llvm-svn: 254476
Summary: Supports the parsing of the "using namespace XXX" and "using XXX::XXX" directives. Added ambiguity errors when it two decls with the same name are encountered (see comments in TestCppNsImport). Fixes using directives being duplicated for anonymous namespaces. Fixes GetDeclForUID for specification DIEs.
Reviewers: sivachandra, chaoren, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12897
llvm-svn: 247836
Summary: SymbolFileDWARF now creates VarDecl and BlockDecl and adds them to the Decl tree. Then, in ClangExpressionDeclMap it uses the Decl tree to search for a variable. This fixes lots of variable scoping problems.
Reviewers: sivachandra, chaoren, spyffe, clayborg
Subscribers: tberghammer, jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D12658
llvm-svn: 247746
class DWARFASTParser
{
public:
virtual ~DWARFASTParser() {}
virtual lldb::TypeSP
ParseTypeFromDWARF (const lldb_private::SymbolContext& sc,
const DWARFDIE &die,
lldb_private::Log *log,
bool *type_is_new_ptr) = 0;
virtual lldb_private::Function *
ParseFunctionFromDWARF (const lldb_private::SymbolContext& sc,
const DWARFDIE &die) = 0;
virtual bool
CompleteTypeFromDWARF (const DWARFDIE &die,
lldb_private::Type *type,
lldb_private::CompilerType &clang_type) = 0;
virtual lldb_private::CompilerDeclContext
GetDeclContextForUIDFromDWARF (const DWARFDIE &die) = 0;
virtual lldb_private::CompilerDeclContext
GetDeclContextContainingUIDFromDWARF (const DWARFDIE &die) = 0;
};
We have one subclass named DWARFASTParserClang that implements all of the clang specific AST type parsing. This keeps all DWARF parsing in the DWARF plug-in. Moved all of the DWARF parsing code that was in ClangASTContext over into DWARFASTParserClang.
lldb_private::TypeSystem classes no longer have any DWARF parsing functions in them, but they can hand out a DWARFASTParser:
virtual DWARFASTParser *
GetDWARFParser ()
{
return nullptr;
}
This keeps things clean and makes for easy merging when we have different AST's for different languages.
llvm-svn: 246242
