Summary:
GCC does not emit DW_AT_data_member_location for members of a union.
Starting with a 0 value for member locations helps is reading union types
in such cases.
Reviewers: clayborg
Subscribers: ldrumm, lldb-commits
Differential Revision: http://reviews.llvm.org/D18008
llvm-svn: 263085
Previously line table parsing code assumed that the only gaps would
occur at the end of functions. In practice this isn't true, so this
patch makes the line table parsing more robust in the face of
functions with non-contiguous byte arrangements.
llvm-svn: 263078
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
The purpose of these plugins is to make LLDB capable of debugging java
code JIT-ed by the android runtime.
Differential revision: http://reviews.llvm.org/D17616
llvm-svn: 262015
Additionally fix the type of some dwarf expression where we had a
confusion between scalar and load address types after a dereference.
Differential revision: http://reviews.llvm.org/D17604
llvm-svn: 262014
DWARF stores this information in the DW_AT_start_scope attribute. This
CL add support for this attribute and also changes the functions
displaying frame variables to only display the variables currently in
scope.
Differential revision: http://reviews.llvm.org/D17449
llvm-svn: 261858
Inline functions in DWARF have AT_abstract_origin set, but we only handled that
if the functions were C++ methods. Inline functions -- C or C++ -- have this
also, and as a result they got one FunctionDecl for each inlined instance. When
going to construct the locals, this meant that the arguments (which did properly
have their abstract origins handled) would get associated with the master
FunctionDecl, and the inlined FunctionDecls would all appear to have no locals.
This manifested as not being able to look up local variables when stopped in an
inline fuunction. We should have had a test for this, but somewhere along the
line the relevant test case lost its .py file (or it never had one).
This patch fixes this problem and restores the .py file.
<rdar://problem/24712434>
llvm-svn: 261598
the xcode project file to catch switch statements that have a
case that falls through unintentionally.
Define LLVM_FALLTHROUGH to indicate instances where a case has code
and intends to fall through. This should be in llvm/Support/Compiler.h;
Peter Collingbourne originally checked in there (r237766), then
reverted (r237941) because he didn't have time to mark up all the
'case' statements that were intended to fall through. I put together
a patch to get this back in llvm http://reviews.llvm.org/D17063 but
it hasn't been approved in the past week. I added a new
lldb-private-defines.h to hold the definition for now.
Every place in lldb where there is a comment that the fall-through
is intentional, I added LLVM_FALLTHROUGH to silence the warning.
I haven't tried to identify whether the fallthrough is a bug or
not in the other places.
I haven't tried to add this to the cmake option build flags.
This warning will only work for clang.
This build cleanly (with some new warnings) on macosx with clang
under xcodebuild, but if this causes problems for people on other
configurations, I'll back it out.
llvm-svn: 260930
assert(((SymbolFileDWARF*)m_ast.GetSymbolFile())->UserIDMatches(die.GetDIERef().GetUID()) &&
"Adding incorrect type to forward declaration map");
The problem is that "m_ast.GetSymbolFile()" can return a SymbolFileDWARFDebugMap. The code is doing the right thing if the assertion is ignored.
<rdar://problem/24437972>
llvm-svn: 260618
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files
Each time a SymbolFile::FindTypes() is called, it needs to check the searched_symbol_files list to make sure it hasn't already been asked to find the type and return immediately if it has been checked. This will stop circular dependencies from also crashing LLDB during type queries.
This has proven to be an issue when debugging large applications on MacOSX that use DWARF in .o files.
<rdar://problem/24581488>
llvm-svn: 260434
1) Turns out we weren't correctly uniquing types for C++. We would search our repository for "lldb_private::Process", but yet store just "Process" in the unique type map. Now we store things correctly and correctly unique types.
2) SymbolFileDWARF::CompleteType() can be called at any time in order to complete a C++ or Objective C class. All public inquiries into the SymbolFile go through SymbolVendor, and SymbolVendor correctly takes the module lock before it call the SymbolFile API call, but when we let CompilerType objects out in the wild, they can complete themselves at any time from the expression parser, so the ValueObjects or (SBValue objects in the public API), and many more places. So we now take the module lock when completing a type to avoid two threads being in the SymbolFileDWARF at the same time.
3) If a class has a template member function like:
class A
{
<template T>
void Foo(T t);
};
The DWARF will _only_ contain a DW_TAG_subprogram for "Foo" if anyone specialized it. This would cause a class definition for A inside a.cpp that used a "int" and "float" overload to look like:
class A
{
void Foo(int t);
void Foo(double t);
};
And a version from b.cpp that used a "float" overload to look like:
class A
{
void Foo(float t);
};
And a version from c.cpp that use no overloads to look like:
class A
{
};
Then in an expression if you have two variables, one name "a" from a.cpp in liba.dylib, and one named "b" from b.cpp in libb.dylib, you will get conflicting definitions for "A" and your expression will fail. This all stems from the fact that DWARF _only_ emits template specializations, not generic definitions, and they are only emitted if they are used. There are two solutions to this:
a) When ever you run into ANY class, you must say "just because this class doesn't have templatized member functions, it doesn't mean that any other instances might not have any, so when ever I run into ANY class, I must parse all compile units and parse all instances of class "A" just in case it has member functions that are templatized.". That is really bad because it means you always pull in ALL DWARF that contains most likely exact duplicate definitions of the class "A" and you bloat the memory that the SymbolFileDWARF plug-in uses in LLDB (since you pull in all DIEs from all compile units that contain a "A" definition) uses for little value most of the time.
b) Modify DWARF to emit generic template member function definitions so that you know from looking at any instance of class "A" wether it has template member functions or not. In order to do this, we would have to have the ability to correctly parse a member function template, but there is a compiler bug:
<rdar://problem/24515533> [PR 26553] C++ Debug info should reference DW_TAG_template_type_parameter
This bugs means that not all of the info needed to correctly make a template member function is in the DWARF. The main source of the problem is if we have DWARF for a template instantiation for "int" like: "void A::Foo<int>(T)" the DWARF comes out as "void A::Foo<int>(int)" (it doesn't mention type "T", it resolves the type to the specialized type to "int"). But if you actually have your function defined as "<template T> void Foo(int t)" and you only use T for local variables inside the function call, we can't correctly make the function prototype up in the clang::ASTContext.
So the best we can do for now we just omit all member functions that are templatized from the class definition so that "A" never has any template member functions. This means all defintions of "A" look like:
class A
{
};
And our expressions will work. You won't be able to call template member fucntions in expressions (not a regression, we weren't able to do this before) and if you are stopped in a templatized member function, we won't know that are are in a method of class "A". All things we should fix, but we need <rdar://problem/24515533> fixed first, followed by:
<rdar://problem/24515624> Classes should always include a template subprogram definition, even when no template member functions are used
before we can do anything about it in LLDB.
This bug mainly fixed the following Apple radar:
<rdar://problem/24483905>
llvm-svn: 260308
A DWARF language vender extension for RenderScript was added to LLVM in r259348(http://reviews.llvm.org/D16409)
We should use this generated enum instead of the hardcoded value.
RenderScript is also based on C99 with some extensions, so we want to use ClangASTContext when RS is detected.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16766
llvm-svn: 259634
A lot of C code uses code like:
typedef struct
{
int a;
} FooType;
This creates debug info with an anonymous struct (a DW_TAG_structure_type with no DW_AT_name) and then a DW_TAG_typedef that points to the anonymous structure type. When a typedef is from a module and clang uses -gmodules and -fmodules, then we can end up trying to resolve an anonymous structure type in a DWO symbol file. This doesn't work very well when the structuture has no name, so we now check if a typedef comes from a module, and we directly resolve the typedef type in the module and copy it over. The version we copy from the module of course is correctly able to find the structure in the DWO symbol file, so this fixes the issues we run into.
<rdar://problem/24092915>
llvm-svn: 258443
If your program refers to modules (as indicated in DWARF) we will now try to
load these modules and give you access to their types in expressions. This used
to be gated by a setting ("settings set target.auto-import-clang-modules true")
but that setting defaulted to false. Now it defaults to true -- but you can
disable it by toggling the setting to false.
llvm-svn: 257812
We have a check what warns if the offset of a class member is greater
then or equal to the size of the class. The warning is valid in most
case but it is invalid when the last data member is a 0 size array
because in this case the member offset can be equal to the class size
(subject to alignment limitations).
This CL fixis LLDB to not print out a warning in this special case.
llvm-svn: 257603
Previously we tried to parse the line table even if a compile unit
had no DW_AT_stmt_list atribute. The problem happens when a compiler
generates debug info for a compile unit but doesn't generate any line
info.
llvm-svn: 257335
Summary:
This change is relevant for inferiors compiled with GCC. GCC does not
emit complete debug info for std::basic_string<...>, and consequently, Clang
(the LLDB compiler) does not generate correct mangled names for certain
functions.
This change removes the hard-coded alternate names in
ItaniumABILanguageRuntime.cpp.
Before the hard-coded names were put in ItaniumABILanguageRuntime.cpp, one could
not evaluate std::string methods (ex. std::string::length). After putting in
the hard-coded names, one could evaluate them. However, it did not still
enable one to call methods on, say for example, std::vector<string>.
This change makes that possible.
There is some amount of incompleteness in this change. Consider the
following example:
std::string hello("hello"), world("world");
std::map<std::string, std::string> m;
m[hello] = world;
One can still not evaluate the expression "m[hello]" in LLDB. Will
address this issue in another pass.
Reviewers: jingham, vharron, evgeny777, spyffe, dawn
Subscribers: clayborg, dawn, lldb-commits
Differential Revision: http://reviews.llvm.org/D12809
llvm-svn: 257113
Reverts "Use correct format identifiers to print something meaningful."
Original format specifiers were correct.
Instead use void* casts to remove warnings, since this is what the %p specifier expects.
llvm-svn: 256833
This patch adds support for printing global static const variables which are given a DW_AT_const_value DWARF tag by clang.
Fix for bug https://llvm.org/bugs/show_bug.cgi?id=25653
Reviewers: clayborg, tberghammer
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D15576
llvm-svn: 255887
Summary:
DWARF 5 proposes a reinvented .debug_macro section. This change follows
that spec.
Currently, only GCC produces the .debug_macro section and hence
the added test is annottated with expectedFailureClang.
Reviewers: spyffe, clayborg, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15437
llvm-svn: 255729
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
A very expected layout: source tree is in ~/src/llvm, the build directory is in
~/src/llvm-build, and the install location is in /usr/local/{lib,include}.
The DWARF information in /usr/local/lib/libLLVM.a for ilist.h points to
~/src/llvm-build/include/llvm/ADT/ilist.h. Now, when someone includes
"llvm/ADT/ilist.h" and links against /usr/local/lib/libLLVM.a. Disaster.
The DWARF information in libUser.so for ilist.h points to two locations: the one
in /usr/include, and the one in ~/src/llvm-build/include. LLDB gets confused.
Let's uniquify fully-qualified names and never trip on such a thing.
Differential Revision: http://reviews.llvm.org/D14549
llvm-svn: 252898
Summary:
The solution to bug 24074,rL249673 needed
to parse the function information from the Dwarf in order
to set the SymbolContext. For that, GetFunction was called
for the parent in GetTypeForDIE, which parses the
ChildParameters and in the flow, GetTypeForDIE was called
for one of the sibling die and so an infinite
loop was triggered by calling GetFunction repeatedly for the
same function.
The changes in this revision modify the GetTypeForDIE to only
resolve the function context in the Type Lookup flow and so
prevent the infinite loop.
A testcase has also been added to check for regression in the
future and a test vector had been added to the testcase of
24074.
Reviewers: jingham, tberghammer, clayborg
Differential Revision: http://reviews.llvm.org/D14202
llvm-svn: 251917
Also since we always read in the DWARF data or mmap it, we don't need to make a copy of the strings for the directories and file names, we can just store "cosnt char *" values. Every place that uses the prologues use them temporarily and then throw them away so no one is expecting the directory and filename strings to live longer than the parse functions.
llvm-svn: 251310
Re-commit the change after fixing a lot of race condition in LLDB
exposed by this change
Loading the debug info from a large application is the slowest task
LLDB do. This CL makes most of the dwarf parsing code multi-threaded.
As a result the speed of "attach; backtrace; exit;" when the inferior
is an LLDB with full debug info increased by a factor of 2.
Differential revision: http://reviews.llvm.org/D13662
llvm-svn: 251106
Revert it bacuse it introduces several race condition detected by
the build bots.
This reverts commit 5107a5ebdb7c4571a30a7098b40bf8098b678447.
llvm-svn: 250832
Loading the debug info from a large application is the slowest task
LLDB do. This CL makes most of the dwarf parsing code multi-threaded.
As a result the speed of "attach; backtrace; exit;" when the inferior
is an LLDB with full debug info increased by a factor of 2 (on my machine).
Differential revision: http://reviews.llvm.org/D13662
llvm-svn: 250821
There were a number of const qualifiers being cast away which caused warnings.
This cluttered the output hiding real errors. Silence them by explicit casting.
NFC.
llvm-svn: 250662
Summary:
In bug 24074, the type information is not shown
correctly. This commit includes the following -
-> Changes for displaying correct type based on
current lexical scope for the command "image
lookup -t"
-> The corresponding testcase.
-> This patch was reverted due to segfaults in
FreeBSD and Mac, I fixed the problems for both now.
Reviewers: emaste, granata.enrico, jingham, clayborg
Differential Revision: http://reviews.llvm.org/D13290
llvm-svn: 249673
Summary: This change fixes pr24916. As associated test has been added.
Reviewers: clayborg
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D13224
llvm-svn: 249629
There are still a bunch of dependencies on the plug-in, but this helps to
identify them.
There are also a few more bits we need to move (and abstract, for example the
ClangPersistentVariables).
llvm-svn: 248612
Summary:
With this change DWARFASTParserClang::CompleteTypeFromDWARF returns false if
DWARFASTParserClang::ParseChildMembers returns false. Similarly, it returns
false if any base class is of an incomplete type. This helps in cases like
these:
class Foo
{
public:
std::string str;
};
...
Foo f;
If a file with the above code is compiled with a modern clang but without
the -fno-limit-debug-info (or similar) option, then the DWARF has only
a forward declration for std::string. In which case, the type for
"class Foo" cannot be completed. If LLDB does not detect that a child
member has incomplete type, then it wrongly conveys to clang (the LLDB
compiler) that "class Foo" is complete, and consequently crashes due to
an assertion failure in clang when running commands like "p f" or
"frame var f".
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13066
llvm-svn: 248401
Summary:
In bug 24074, the type information is not shown
correctly. This commit includes the following -
-> Changes for displaying correct type based on
current lexical scope for the command "image
lookup -t"
-> The corresponding testcase.
Reviewers: jingham, ovyalov, spyffe, richard.mitton, clayborg
Differential Revision: http://reviews.llvm.org/D12404
llvm-svn: 248366
Summary:
This is no longer related to Clang and is just an opaque pointer
to data for a compiler type.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13039
llvm-svn: 248288
Summary:
With the recent changes to separate clang from the core structures
of LLDB, many inclusions of clang headers can be removed.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12954
llvm-svn: 248004
This cleans up type systems to be more pluggable. Prior to this we had issues:
- Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()"
- Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem
- Cleaned up Module so that it no longer has dedicated type system member variables:
lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module.
lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module.
Now we have a type system map:
typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap;
TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module
- Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract:
class CompilerType
{
...
//----------------------------------------------------------------------
// Return a new CompilerType that is a L value reference to this type if
// this type is valid and the type system supports L value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetLValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType that is a R value reference to this type if
// this type is valid and the type system supports R value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetRValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a const modifier to this type if
// this type is valid and the type system supports const modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddConstModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a volatile modifier to this type if
// this type is valid and the type system supports volatile modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddVolatileModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a restrict modifier to this type if
// this type is valid and the type system supports restrict modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddRestrictModifier () const;
//----------------------------------------------------------------------
// Create a typedef to this type using "name" as the name of the typedef
// this type is valid and the type system supports typedefs, else return
// an invalid type.
//----------------------------------------------------------------------
CompilerType
CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const;
};
Other changes include:
- Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);"
- Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed
llvm-svn: 247953
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
Split-dwarf uses a different header format to specify the address range
for the elements of the location lists.
Differential revision: http://reviews.llvm.org/D12880
llvm-svn: 247789
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
The iterator pointing to an element of a dense map was used after
the element from was removed from the map what isn't guaranteed to be
valid at that time.
llvm-svn: 247571
* Create new dwo symbol file class
* Add handling for .dwo sections
* Change indexes in SymbolFileDWARF to store compile unit offset next to
DIE offset
* Propagate queries from dwarf compile unit to the dwo compile unit
where applicable
Differential revision: http://reviews.llvm.org/D12291
llvm-svn: 247132
* Remove some unused code
* Remove usage of DWARFDebugInfoEntry::Attributes where usage isn't
reasonable
* Cleanup DWARFMappedHash with separating it to header and implementation
file and fixing the visibility of the functions
Differential revision: http://reviews.llvm.org/D12374
llvm-svn: 247131
This will keep our code cleaner and it removes the need for intrusive additions to TypeSystem like:
class TypeSystem
{
virtual ClangASTContext *
AsClangASTContext() = 0;
}
As you can now just use the llvm::dyn_cast and other casts.
llvm-svn: 247041
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
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
Added a new class called DWARFDIE that contains a DWARFCompileUnit and DWARFDebugInfoEntry so that these items always stay together.
There were many places where we just handed out DWARFDebugInfoEntry pointers and then use them with a compile unit that may or may not be the correct one. Clients outside of DWARFCompileUnit and DWARFDebugInfoEntry should all be dealing with DWARFDIE instances instead of playing with DWARFCompileUnit/DWARFDebugInfoEntry pairs manually.
This paves to the way for some modifications that are coming for DWO.
llvm-svn: 246100
These are 2 new value currently in experimental status used when split
debug info is enabled.
Differential revision: http://reviews.llvm.org/D12238
llvm-svn: 245931
The array is indexed by the value in the DW_FORM filed what can be
bigger then the size of the array. This CL add bound checking to avoid
buffer overflows
Differential revision: http://reviews.llvm.org/D12239
llvm-svn: 245930
Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files.
Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types.
Bulk renames for things that used to return a ClangASTType which is now CompilerType:
"Type::GetClangFullType()" to "Type::GetFullCompilerType()"
"Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()"
"Type::GetClangForwardType()" to "Type::GetForwardCompilerType()"
"Value::GetClangType()" to "Value::GetCompilerType()"
"Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)"
"ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()"
many more renames that are similar.
llvm-svn: 245905
Another step towards isolating all language/AST specific code into the files to further abstract specific implementations of parsing types for a given language.
llvm-svn: 245090
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).
llvm-svn: 244689
This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system.
All tests pass on MacOSX and passed on linux the last time this was submitted.
llvm-svn: 244679
is optimized into DWARFCompileUnit, where it should have
been. Next I'll need to call this from another section
of code for DWARF-in-.o-file behavior correctness.
llvm-svn: 243736
debugging optimized code. Adds new methods on Function/SBFunction
to query whether a given function is optimized. Adds a new
function.is-optimized format entity and changes the default
frame-format to append "[opt]" if the function was built with
optimization.
The only indication that a binary was built with optimization
that we have right now is the presence of the DW_AT_APPLE_optimized
attribute (DW_FORM_flag value 1) in the DW_TAG_compile_unit.
The absence of this flag may mean that the compile_unit was not
compiled with optimization, or it may mean that the producer
does not generate this attribute.
Currently this only works for dSYM debugging. When we create
the CompileUnit with dwarf-in-.o-file debugging we don't have
the attribute value yet so it's not set. I need to find the
flag value when we do start to read the .o file DWARF and
set the CompileUnit's status at that point - but haven't
done it yet.
I'm also going to add a mechanism for issuing warnings to users
such that they're only issued once in a debug session and
there is away for users to suppress these warnings altogether
via .lldbinit file settings. But I want to get this changeset
committed now that it's at a useful state.
<rdar://problem/19281172>
llvm-svn: 243508
Summary:
The DW_AT_name attribute of compile unit is optional.
If it is missing, try to get filename from the debug_line section.
This allows the compile unit to be useful without the filename.
Differential Revision: http://reviews.llvm.org/D11003
llvm-svn: 241679
A few extras were fixed
- Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected.
- Since some places want to access the address as a reference, I added a few new functions to symbol:
Address &Symbol::GetAddressRef();
const Address &Symbol::GetAddressRef() const;
Linux test suite passes just fine now.
<rdar://problem/21494354>
llvm-svn: 240702
Summary:
* Fix enum LanguageType values so that they can be used as indexes
into array language_names and g_languages as assumed by
LanguageRuntime::GetNameForLanguageType,
Language::SetLanguageFromCString and Language::AsCString.
* Add DWARFCompileUnit::LanguageTypeFromDWARF to convert from DWARF
DW_LANG_* values to enum LanguageType values.
Reviewed By: clayborg, abidh
Differential Revision: http://reviews.llvm.org/D10484
llvm-svn: 239963
Summary:
`IsRelativeToCurrentWorkingDirectory` was misleading, because relative paths
are sometimes appended to other directories, not just the cwd. Plus, the new
name is shorter. Also added `IsAbsolute` for completeness.
Reviewers: clayborg, ovyalov
Reviewed By: ovyalov
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D10262
llvm-svn: 239419
A DW_TAG_subprogram entry can contain a reference to a
DW_AT_abstract_origin entry instead of duplicating the information
from it (e.g.: name) when the same function is inlined in some case
and not inlined in other cases.
This CL fixes name parsing for the case when the DW_TAG_subprogram
for the non inlined version contains just a reference to the
DW_AT_abstract_origin entry instead of the full information.
Differential revision: http://reviews.llvm.org/D10034
llvm-svn: 238307
In http://reviews.llvm.org/D9754 I enabled the mangled symbol name lookup
workaround used to find global and anonymous namespace symbols in linux binaries
for all platforms, however we should still only check for these symbols when
processing Linux or FreeBSD binaries where they are relevant. This patch makes
this change.
Test Plan: The tests from the original revision still pass:
TestCallCPPFunction.py
TestCallStopAndContinue.py
TestExprs.py
TestExprsChar.py
TestNamespace.py
TestOverloadedFunctions.py
TestRvalueReferences.py
TestThreadExit.py
Differential Revision: http://reviews.llvm.org/D9782
llvm-svn: 237467
all hosts.
We require a workaround to be able to locate global and anonymous namespace
functions in the dwarf symbols on linux binaries. This patch enables this code
on all platforms so that we can still find these symbols when debugging from a
different host platform.
Test Plan:
The following tests begin passing when running with a mac host to linux client:
TestCallCPPFunction.py
TestCallStopAndContinue.py
TestExprs.py
TestExprsChar.py
TestNamespace.py
TestOverloadedFunctions.py
TestRvalueReferences.py
TestThreadExit.py
Differential Revision: http://reviews.llvm.org/D9754
llvm-svn: 237270
Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.
Differential Revision: http://reviews.llvm.org/D9674
llvm-svn: 237218
module-loading support for the expression parser.
- It adds support for auto-loading modules referred
to by a compile unit. These references are
currently in the form of empty translation units.
This functionality is gated by the setting
target.auto-import-clang-modules (boolean) = false
- It improves and corrects support for loading
macros from modules, currently by textually
pasting all #defines into the user's expression.
The improvements center around including only those
modules that are relevant to the current context -
hand-loaded modules and the modules that are imported
from the current compile unit.
- It adds an "opt-in" mechanism for all of this
functionality. Modules have to be explicitly
imported (via @import) or auto-loaded (by enabling
the above setting) to enable any of this
functionality.
It also adds support to the compile unit and symbol
file code to deal with empty translation units that
indicate module imports, and plumbs this through to
the CompileUnit interface.
Finally, it makes the following changes to the test
suite:
- It adds a testcase that verifies that modules are
automatically loaded when the appropriate setting
is enabled (lang/objc/modules-auto-import); and
- It modifies lanb/objc/modules-incomplete to test
the case where a module #undefs something that is
#defined in another module.
<rdar://problem/20299554>
llvm-svn: 235313
files. Before we'd give up if we found a .o that doesn't have
DWARF associated with it; now we iterate through them all.
Also made this iteration a higher-order function so that people
don't have to remember to do this right.
<rdar://problem/20261196>
llvm-svn: 233838
Summary:
This is similar to the change introduced for variable DIEs in r233098. If the
linkage names of functions are missing in the DWARF, then their fully qualified
names (similar to the name that would be got by demangling their linkage name)
is generated using the decl context.
This change fixes TestNamespace when the test case is compiled with GCC, hence
it is enabled for GCC. The test and the test case are also enhanced to cover
variadic functions.
Test Plan: dotest.py -C <clang|gcc> -p TestNamespace
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8623
llvm-svn: 233336
Since ClangASTSource::layoutRecordType() was overriding a virtual
function in the base, this was inadvertently causing a new method
to be introduced rather than an override. To fix this all method
signatures are changed back to taking DenseMaps, and the `override`
keyword is added to make sure this type of error doesn't happen
again.
To keep the original fix intact, which is that fields and bases
must be added in offset order, the ImportOffsetMap() function
now copies the DenseMap into a vector and then sorts the vector
on the value type (e.g. the offset) before iterating over the
sorted vector and inserting the items.
llvm-svn: 233099
Summary:
This commit adds this alternate route only when parsing variable dies
corresponding to global or static variables. The motivation for this is that GCC
does not emit linkage names for functions and variables declared/defined in
anonymous namespaces. Having this alternate route fixes one part of
TestNamespace which fails when the test case is compiled with GCC.
An alternate route to get fully qualified names of functions whose linkage names
are missing will be added with a followup change. With that, the other failing
part of TestNamespace will also be fixed.
Test Plan: dotest.py -C gcc -p TestNamespace
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8569
llvm-svn: 233098
Prior to this patch, we would try to synthesize class types by
iterating over a DenseMap of FieldDecls and adding each one to
a CXXRecordDecl. Since a DenseMap doesn't provide a deterministic
ordering of the elements, this would not add the fields in
FieldOffset order, but rather in some random order determined by
the memory layout of the DenseMap.
This patch fixes the issue by changing DenseMaps to vectors. The
ability to lookup a value in the DenseMap was hardly being used,
and where it is sufficient to do a vector lookup.
Differential Revision: http://reviews.llvm.org/D8512
llvm-svn: 233090
Summary:
SymbolFileDWARF was not respecting the include_inlines argument in function lookup in all code
paths. This resulted in an attempt to call an inlined function during expression evaluation,
which is impossible, and usually resulted in a segfault in the inferior. This patch makes sure
include_inlines is respected in all code paths.
Reviewers: clayborg
Subscribers: lldb-commits, sivachandra
Differential Revision: http://reviews.llvm.org/D8286
llvm-svn: 232151
When we have a debug map we have an executable with a bunch of STAB symbols and each source file has a N_SO symbol which scopes a bunch of symbols inside of it. We can use this to our advantage here when looking for the complete definition of an objective C class by looking for a symbol whose name matches the class name and whose type is eSymbolTypeObjCClass. If we find one, that symbol will be contained within a N_SO symbol. This symbol gets turned into a symbol whose type is eSymbolTypeSourceFile and that symbol will contain the eSymbolTypeObjCClass which helps us to locate the correct .o file and allows us to only look in that file.
To further accelerate things, if we are looking for the implementation, we can avoid looking at all .o files if we don't find a matching symbol because we have a debug map, which means the objective C symbol for the class can't have been stripped, so we can safely not search all remaining .o files. This will save us lots of time when trying to look for "NSObject" and any other AppKit and Foundation classes that we never have implementation definitions for.
<rdar://problem/19234225>
llvm-svn: 230562
Now we make sure to update our DWARFCompileUnit -> lldb_private::CompileUnit user data when it isn't set to ensure quick transitions between the two.
<rdar://problem/18371367>
llvm-svn: 228264
This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for)
The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee)
This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help
No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet
llvm-svn: 227274
The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918
and also to break a dependency cascade that caused functions linking
in string->int conversion functions to pull in most of lldb
llvm-svn: 226199
This is done by adding a "Variable *" to SymbolContext and allowing SymbolFile::ResolveSymbolContext() so if an address is resolved into a symbol context, we can include the global or static variable for that address.
This means you can now find global variables that are merged globals when doing a "image lookup --verbose --address 0x1230000". Previously we would resolve a symbol and show "_MergedGlobals123 + 1234". But now we can show the global variable name.
The eSymbolContextEverything purposely does not include the new eSymbolContextVariable in its lookup since stack frame code does many lookups and we don't want it triggering the global variable lookups.
<rdar://problem/18945678>
llvm-svn: 226084
Summary:
GCC emits DW_TAG_subrange_type for static member arrays, but with no
attributes. This in turn results in wrong type/value of the array when
printing with 'target variable <array var name>'. This patch fixes this
so that the array value is printed in this format:
(<element type> []) <array var name> = {}
Earlier, the array was being interpreted to be of its element type.
Note: This does not fix anything to do with 'expr' or 'p' commands.
Those commands still error out complaining about incomplete types.
Test Plan: dotest.py -p TestStaticVariables
Reviewers: emaste, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6799
llvm-svn: 225219
Greg Clayton