building method override tables for CXXMethodDecls in
DWARFASTParserClang::CompleteTypeFromDWARF.
C++ virtual method calls in LLDB expressions may fail if the override table for
the method being called is not correct as IRGen will produce references to the
wrong (or a missing) vtable entry.
This patch does not fix calls to virtual methods with covariant return types as
it mistakenly treats these as overloads, rather than overrides. This will be
addressed in a future patch.
Review: https://reviews.llvm.org/D41997
Partially fixes <rdar://problem/14205774>
llvm-svn: 323163
This fixes a bug in -gmodules DWARF handling when debugging without a .dSYM bundle
that was particularly noticable when debugging LLVM itself.
Debugging without clang modules and DWO handling should be unaffected by this patch.
<rdar://problem/32436209>
llvm-svn: 321802
It was completly unused and broke the part of the encapsulation that
common code shouldn't depend on specific plugins or language specific
features.
llvm-svn: 311000
Templates can end in parameter packs, like this
template <class T...> struct MyStruct
{ /*...*/ };
LLDB does not currently support these parameter packs;
it does not emit them into the template argument list
at all. This causes problems when you specialize, e.g.:
template <> struct MyStruct<int>
{ /*...*/ };
template <> struct MyStruct<int, int> : MyStruct<int>
{ /*...*/ };
LLDB generates two template specializations, each with
no template arguments, and then when they are imported
by the ASTImporter into a parser's AST context we get a
single specialization that inherits from itself,
causing Clang's record layout mechanism to smash its
stack.
This patch fixes the problem for classes and adds
tests. The tests for functions fail because Clang's
ASTImporter can't import them at the moment, so I've
xfailed that test.
Differential Revision: https://reviews.llvm.org/D33025
llvm-svn: 302833
Summary:
UniqueCStringMap "sorts" the entries for fast lookup, but really it only cares about uniqueness. ConstString can be compared by pointer alone, rather than with strcmp, resulting in much faster comparisons. Change the interface to take ConstString instead, and propagate use of the type to the callers where appropriate.
Reviewers: #lldb, clayborg
Reviewed By: clayborg
Subscribers: labath, jasonmolenda, lldb-commits
Differential Revision: https://reviews.llvm.org/D32316
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 301908
LLDB uses clang::DeclContexts for lookups, and variables get put into
the DeclContext for their abstract origin. (The abstract origin is a
DWARF pointer that indicates the unique definition of inlined code.)
When the expression parser is looking for variables, it locates the
DeclContext for the current context. This needs to be done carefully,
though, e.g.:
__attribute__ ((always_inline)) void f(int a) {
{
int b = a * 2;
}
}
void g() {
f(3);
}
Here, if we're stopped in the inlined copy of f, we have to find the
DeclContext corresponding to the definition of f – its abstract
origin. Clang doesn't allow multiple functions with the same name and
arguments to exist. It also means that any variables we see must be
placed in the appropriate DeclContext.
[Bug 1]: When stopped in an inline block, the function
GetDeclContextDIEContainingDIE for that block doesn't properly
construct a DeclContext for the abstract origin for inlined
subroutines. That means we get duplicated function DeclContexts, but
function arguments only get put in the abstract origin's DeclContext,
and as a result when we try to look for them in nested contexts they
aren't found.
[Bug 2]: When stopped in an inline block, the DWARF (for space
reasons) doesn't explicitly point to the abstract origin for that
block. This means that the function GetClangDeclContextForDIE returns
a different DeclContext for each place the block is inlined. However,
any variables defined in the block have abstract origins, so they
will only get placed in the DeclContext for their abstract origin.
In this fix, I've introduced a test covering both of these issues,
and fixed them.
Bug 1 could be resolved simply by making sure we look up the abstract
origin for inlined functions when looking up their DeclContexts on
behalf of nested blocks.
For Bug 2, I've implemented an algorithm that makes the DeclContext
for a block be the containing DeclContext for the closest entity we
would find during lookup that has an abstract origin pointer. That
means that in the following situation:
{ // block 1
int a;
{ // block 2
int b;
}
}
if we looked up the DeclContext for block 2, we'd find the block
containing the abstract origin of b, and lookup would proceed
correctly because we'd see b and a. However, in the situation
{ // block 1
int a;
{ // block 2
}
}
since there isn't anything to look up in block 2, we can't determine
its abstract origin (and there is no such pointer in the DWARF for
blocks). However, we can walk up the parent chain and find a, and its
abstract origin lives in the abstract origin of block 1. So we simply
say that the DeclContext for block 2 is the same as the DeclContext
for block 1, which contains a. Lookups will return the same results.
Thanks to Jim Ingham for review and suggestions.
Differential revision: https://reviews.llvm.org/D32375
llvm-svn: 301263
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
LLDB needs some minor changes to adopt PrettyStackTrace after https://reviews.llvm.org/D27683.
We remove our own SetCrashDescription() function and use LLVM-provided RAII objects instead.
We also make sure LLDB doesn't define __crashtracer_info__ which would collide with LLVM's definition.
Differential Revision: https://reviews.llvm.org/D27735
llvm-svn: 289711
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.
Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.
Differential Revision: https://reviews.llvm.org/D26698
llvm-svn: 287152
*** 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
Summary:
void typedefs do not have a DW_AT_type attribute, so we end up with an empty encoding_uid
variable. These don't need to be looked up and trying to look that will assert in a debug build.
Reviewers: clayborg
Subscribers: lldb-commits, tberghammer
Differential Revision: http://reviews.llvm.org/D22218
llvm-svn: 275164
We were checking for integer types only before this. So I added the ability for CompilerType objects to check for integer and enum types.
Then I searched for places that were using the CompilerType::IsIntegerType(...) function. Many of these places also wanted to be checking for enumeration types as well, so I have fixed those places. These are in the ABI plug-ins where we are figuring out which arguments would go in where in regisers/stack when making a function call, or determining where the return value would live. The real fix for this is to use clang to compiler a CGFunctionInfo and then modify the code to be able to take the IR and a calling convention and have the backend answer the questions correctly for us so we don't need to create a really bad copy of the ABI in each plug-in, but that is beyond the scope of this bug fix.
Also added a test case to ensure this doesn't regress in the future.
llvm-svn: 273750
Prior to this we would display the typename for "TestObj<-1>" as "TestObj<4294967295>" when we showed the type. Expression parsing could also fail because we would fail to find the mangled name when evaluating expressions.
The issue was we were losing the signed'ness of the template integer parameter in DWARFASTParserClang.cpp.
<rdar://problem/25577041>
llvm-svn: 272434
We need to verify that consecutive bitfields have higher offsets and don't overlap. The issues was found by running a broken version of recent clangs where the bitfield offsets were being emitted incorrectly. To guard against this we now verify and toss out any invalid bitfields and print a message that indicates to file a bug against the compiler.
<rdar://problem/25737621>
llvm-svn: 271343
ClangASTContext::StartTagDeclarationDefinition(...) was starting definitions for any TagType instances that have TagDecl, but ClangASTContext::CompleteTagDeclarationDefinition(...) was getting the type to a CXXRecordDecl with:
clang::CXXRecordDecl *cxx_record_decl = qual_type->getAsCXXRecordDecl();
The problem is that getAsCXXRecordDecl() might dig a bit deeper into a type and dig out a different decl, which means we might call ClangASTContext::StartTagDeclarationDefinition(...), but it might not do anything, and then we might call ClangASTContext::CompleteTagDeclarationDefinition(...) and it might try to complete something that didn't have its definition started and this will crash.
This change fixes that, and also makes sure that starting a definition succeeds before any calls to ClangASTContext::CompleteTagDeclarationDefinition().
<rdar://problem/24091798>
llvm-svn: 270891
m_decl_objects is problematic because it assumes that each VarDecl has a unique
variable associated with it. This is not the case in inline contexts.
Also the information in this map can be reconstructed very easily without
maintaining the map. The rest of the testsuite passes with this cange, and I've
added a testcase covering the inline contexts affected by this.
<rdar://problem/26278502>
llvm-svn: 270474
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.
llvm-svn: 269877
Remove XFAIL from some tests that now pass.
Add XFAIL to some tests that now fail.
Fix a crasher where a null pointer check isn't guarded.
Properly handle all types of errors in SymbolFilePDB.
llvm-svn: 269454
Also added a data formatter that presents them as structs if you use frame
variable to look at their contents. Now the blocks testcase works.
<rdar://problem/15984431>
llvm-svn: 268307
Some older versions of clang emitted bit offsets that were negative and these bitfields would have their bitfield-ness stripped off and it would cause a clang assertion in clang assertions were enabled. I updated the bitfield C test to make sure we don't regress.
<rdar://problem/21082998>
llvm-svn: 267248
1 - DWARF in .o files with debug map in executable: we would place the compile unit index in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset
2 - DWO: we would place the compile unit offset in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset
There was a mixing and matching of this and it wasn't done consistently.
Major changes include:
The DIERef constructor that takes a lldb::user_id_t now requires a SymbolFileDWARF:
DIERef(lldb::user_id_t uid, SymbolFileDWARF *dwarf)
It is needed so that it can be decoded correctly. If it is DWARF in .o files with debug map in executable, then we get the right compile unit from the SymbolFileDWARFDebugMap, otherwise, we use the compile unit offset and DIE offset for DWO or normal DWARF.
The function:
lldb::user_id_t DIERef::GetUID() const;
Now becomes
lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf) const;
Again, we need the DWARF file to encode it correctly.
This removes the need for "lldb::user_id_t SymbolFileDWARF::MakeUserID() const" and for bool SymbolFileDWARF::UserIDMatches (lldb::user_id_t uid) const". There were also many places were doing things inneficiently like:
1 - encode a dw_offset_t into a lldb::user_id_t
2 - call the public SymbolFile interface to resolve types using the lldb::user_id_t
3 - This would then decode the lldb::user_id_t into a DIERef, and then try to find that type.
There are many places that are now doing this more efficiently by storing DW_AT_type form values as DWARFFormValue objects and then making a DIERef from them and directly calling the underlying function to resolve the lldb_private::Type, lldb_private::CompilerType, lldb_private::CompilerDecl, lldb_private::CompilerDeclContext.
If there are any regressions in DWARF with DWO, we will need to fix any issues that arise since the original patch wasn't functional for the much more widely used DWARF in .o files with debug map.
<rdar://problem/25200976>
llvm-svn: 264909
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
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
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
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
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 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
