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
Tamas Berghammer