This updates getters and setters to use StringRef instead of
const char *. I tested the build on Linux, Windows, and OSX
and saw no build or test failures. I cannot test any BSD
or Android variants, however I expect the required changes
to be minimal or non-existant.
llvm-svn: 282079
It is a new attribute emitted by clang as a GNU extension and will
be part of Dwarf5. The purpose of the attribute is to specify a compile
unit level base value for all DW_AT_ranges to reduce the number of
relocations have to be done by the linker.
Fixes (at least partially): https://llvm.org/pr28826
Differential revision: https://reviews.llvm.org/D24514
llvm-svn: 281595
*** 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
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
This introduces basic support for debugging OCaml binaries.
Use of the native compiler with DWARF emission support (see
https://github.com/ocaml/ocaml/pull/574) is required.
Available variables are considered as 64 bits unsigned integers,
their interpretation will be left to a OCaml-made debugging layer.
Differential revision: https://reviews.llvm.org/D22132
llvm-svn: 277443
Summary:
We were checking whether an attribute is in block form by getting the block data pointer, which
was not correct as the pointer be null even if the attribute is in block form. Other places in
the file already use the correct test.
To make this work, I've needed to add DW_FORM_exprlock to the list of "block" forms, which seems
correct as that is how we are parsing it.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22756
llvm-svn: 276735
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
I changed "m_is_optimized" in lldb_private::CompileUnit over to be a lldb::LazyBool so that it can be set to eLazyBoolCalculate if it needs to be parsed later. With SymbolFileDWARFDebugMap, we don't actually open the DWARF in the .o files for each compile unit until later, and we can't tell if a compile unit is optimized ahead of time. So to avoid pulling in all .o right away just so we can answer the questions of "is this compile unit optimized" we defer it until a point where we will have the compile unit parsed.
<rdar://problem/26068360>
llvm-svn: 274585
We had support that assumed that thread local data for a variable could be determined solely from the module in which the variable exists. While this work for linux, it doesn't work for Apple OSs. The DWARF for thread local variables consists of location opcodes that do something like:
DW_OP_const8u (x)
DW_OP_form_tls_address
or
DW_OP_const8u (x)
DW_OP_GNU_push_tls_address
The "x" is allowed to be anything that is needed to determine the location of the variable. For Linux "x" is the offset within the TLS data for a given executable (ModuleSP in LLDB). For Apple OS variants, it is the file address of the data structure that contains a pthread key that can be used with pthread_getspecific() and the offset needed.
This fix passes the "x" along to the thread:
virtual lldb::addr_t
lldb_private::Thread::GetThreadLocalData(const lldb::ModuleSP module, lldb::addr_t tls_file_addr);
Then this is passed along to the DynamicLoader::GetThreadLocalData():
virtual lldb::addr_t
lldb_private::DynamicLoader::GetThreadLocalData(const lldb::ModuleSP module, const lldb::ThreadSP thread, lldb::addr_t tls_file_addr);
This allows each DynamicLoader plug-in do the right thing for the current OS.
The DynamicLoaderMacOSXDYLD was modified to be able to grab the pthread key from the data structure that is in memory and call "void *pthread_getspecific(pthread_key_t key)" to get the value of the thread local storage and it caches it per thread since it never changes.
I had to update the test case to access the thread local data before trying to print it as on Apple OS variants, thread locals are not available unless they have been accessed at least one by the current thread.
I also added a new lldb::ValueType named "eValueTypeVariableThreadLocal" so that we can ask SBValue objects for their ValueType and be able to tell when we have a thread local variable.
<rdar://problem/23308080>
llvm-svn: 274366
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
"ClearDIEs()" was being called too soon, before everyone was done using the DIEs.
This fix delays the calls to ::ClearDIEs() until all compile units have been indexed.
1 - Call "::ExtractDIEsIfNeeded()" on all compile units on separate threads. See if each CU has the DIEs parsed and remember this.
2 - Index all compile units on separate threads.
3 - Clear any DIEs in any compile units that didn't have their DIEs parsed after all compile units have been indexed.
Patch by phlav
Differential Revision: http://reviews.llvm.org/D20738
llvm-svn: 271209
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
llvm::Error requires all errors to be handled. Simply checking the whether there was an error is
not enough, you have to actuall call handle(All)Errors, in case there was an error.
llvm-svn: 268906
Summary:
We were trying to get a DWARFDIE from a CompileUnit belonging to a DWO file. However, this
function does not understand the die encoding used by the DWO files. Instead use GetDIE on the
SymbolFileDWARF, which is overriden in DWO to do the right thing.
Reviewers: clayborg, tberghammer
Subscribers: lldb-commits, ovyalov
Differential Revision: http://reviews.llvm.org/D19927
llvm-svn: 268615
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
This implements a PDBASTParser and corresponding logic in
SymbolFilePDB to do type lookup by name. This is just a first
pass and leaves many aspects of type lookup unimplemented, and
just focuses on laying the framework. With this patch, you should
be able to lookup basic types by name from a PDB.
Full class definitions are not completed yet, we will instead
just return a forward declaration of the class.
Differential Revision: http://reviews.llvm.org/D18848
Reviewed by: Greg Clayton
llvm-svn: 266392
TypeSP SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext (const DWARFDeclContext &dwarf_decl_ctx);
The problem was we might be looking for a type "Foo", and find one from another langauge. Then the DWARFASTParserClang would try to make an AST type using a CompilerType that might return an empty.
This fix makes sure that when we create a DWARFDeclContext from a DWARFDIE that the DWARFDeclContext we set the language of the DIE. Then when we go to find matches for DWARFDeclContext, we end up with bunch of DIEs. We check each DWARFDIE that we found by asking it for its language and making sure the language is compatible with the type system that we want to use. This keeps us from using the wrong types to resolve forward declarations.
<rdar://problem/25276165>
llvm-svn: 265196
Summary:
In case of Dwo, DIERef stores a compile unit offset in the main object file, and not in the dwo.
The implementation of SymbolFileDWARFDwo::GetDIE inherited from SymbolFileDWARF tried to lookup
the compilation unit in the DWO based on the main object file offset (and failed). I change the
implementation to verify the DIERef indeed references compile unit belonging to this dwo and then
lookup the die based on the die offset alone.
Includes a couple of fixes for mismatched struct/class tags.
Reviewers: tberghammer, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18646
llvm-svn: 265011
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
Summary:
Since r264316, clang started adding DW_AT_GNU_dwo_name attribute to dwo files (previously, this
attribute was only present in main object files), breaking pretty much every dwo test. The
problem was that we were treating the presence of said attribute as a signal that we should look
for information in an external object file, and caused us to enter an infinite loop. I fix this
by making sure we do not go looking for an external dwo file if we already *are* parsing a dwo
file.
Reviewers: tberghammer, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18547
llvm-svn: 264729
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
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
Mehdi Amini