| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
| |
dSYM file is created from a binary with no debug info, that has been stripped, or when the .o files are not available when the dSYM is created.
llvm-svn: 157078
|
| |
|
|
|
|
| |
Make sure we can fail to create a compile unit without asserting. We now emit a warning.
llvm-svn: 156956
|
| |
|
|
|
|
| |
Correctly unique a class' methods when we detect that a class has been uniqued to another.
llvm-svn: 156795
|
| |
|
|
|
|
| |
files. We currently have SymbolFile plug-ins which all get the chance to say what they can parse in a symbol file. Prior to this fix we would ask the SymbolFileDWARF plug-in what abilities it had, and it would answer with "everything", and then we would check the SymbolFileSymtab plug-in what abilities it had, in case it had more abilities. The checking that SymbolFileSymtab does is a bit expensive as it pulls in the entire symbol table just to see if it can offer a few scraps of debug information. This causes all stand along DWARF files to pull in their symbol tables even though those symbols will never be used. This fix will check all SymbolFile plug-ins for their abilities and if any plug-in responds with "everything", then we stop the search.
llvm-svn: 155638
|
| |
|
|
|
|
|
|
|
|
|
|
| |
ObjCPlusPlus as Objective-C classes. Really the
compiler should say they have Objective-C runtime
class, but we should be a little more resilient
(we were refusing to find ivars in those classes
before).
Also added a test case.
llvm-svn: 155515
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixed an issue that would happen when using debug map with DWARF in the .o files where we wouldn't ever track down the actual definition for a type when things were in namespaces. We now serialize the decl context information into an intermediate format which allows us to track down the correct definition for a type regardless of which DWARF symbol file it comes from. We do this by creating a "DWARFDeclContext" object that contains the DW_TAG + name for each item in a decl context which we can then use to veto potential accelerator table matches. For example, the accelerator tables store the basename of the type, so if you have "std::vector<int>", we would end up with an accelerator table entry for the type that contained "vector<int>", which we would then search for using a DWARFDeclContext object that contained:
[0] DW_TAG_class_type "vector<int>"
[1] DW_TAG_namespace "std"
This is currently used to track down forward declarations for things like "class a::b::Foo;".
llvm-svn: 155488
|
| |
|
|
|
|
| |
enabled to the Module class. Used this new function in the DWARF parser.
llvm-svn: 155404
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
and pull in the world. This is due to a compiler bug we are tracking (<rdar://problem/11291658>) where forward decls to classes and types are not properly scoped in namespaces, which results in the current LLDB looking for a type it will find many times in the accelerator tables, but never match. For example, when debugging with clang we get a forward decl like:
class AnalysisResolver;
And we will look for it everywhere and find many many matches, but the decl context of those matching DIEs is "clang::AnalysisResolver", so we never match anything, yet we pull in waaayyy too much DWARF in the process.
To enable this logging enable the "lookups" category in the "dwarf" log channel:
(lldb) log enable dwarf lookups
llvm-svn: 155233
|
| |
|
|
|
|
| |
Objective-C methods, and Objective-C properties.
llvm-svn: 154972
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the debug information individual Decls came from.
We've had a metadata infrastructure for a while,
which was intended to solve a problem we've since
dealt with in a different way. (It was meant to
keep track of which definition of an Objective-C
class was the "true" definition, but we now find
it by searching the symbols for the class symbol.)
The metadata is attached to the ExternalASTSource,
which means it has a one-to-one correspondence with
AST contexts.
I've repurposed the metadata infrastructure to
hold the object file and DIE offset for the DWARF
information corresponding to a Decl. There are
methods in ClangASTContext that get and set this
metadata, and the ClangASTImporter is capable of
tracking down the metadata for Decls that have been
copied out of the debug information into the
parser's AST context without using any additional
memory.
To see the metadata, you just have to enable the
expression log:
-
(lldb) log enable lldb expr
-
and watch the import messages. The high 32 bits
of the metadata indicate the index of the object
file in its containing DWARFDebugMap; I have also
added a log which you can use to track that mapping:
-
(lldb) log enable dwarf map
-
This adds 64 bits per Decl, which in my testing
hasn't turned out to be very much (debugging Clang
produces around 6500 Decls in my tests). To track
how much data is being consumed, I've also added a
global variable g_TotalSizeOfMetadata which tracks
the total number of Decls that have metadata in all
active AST contexts.
Right now this metadata is enormously useful for
tracking down bugs in the debug info parser. In the
future I also want to use this information to provide
more intelligent error messages instead of printing
empty source lines wherever Clang refers to the
location where something is defined.
llvm-svn: 154634
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FunctionDecls into classes if it looked up a
method in a different DWARF context than the
one where it found the parent class's definition.
The symptom of this was, for a method A::B(),
1) LLDB finds A in context 1, creating a
CXXRecordDecl for A and marking it as needing
completion
2) LLDB looks up B in context 2, finds that its
parent A already has a CXXRecordDecl, but can't
find a CXXMethodDecl for B
3) Not finding a CXXMethodDecl for B, LLDB doesn't
set the flag indicating that B was resolved
4) Because the flag wasn't set, LLDB's fallthrough
code creates a FunctionDecl for B and sticks it
in the DeclContext -- in this case, A.
5) Clang crashes on finding a FunctionDecl inside a
CXXRecordDecl.
llvm-svn: 154627
|
| |
|
|
|
|
|
|
| |
namespace where if the NamespaceDecl hadn't been parsed yet, we would say a function wasn't in a namespace.
Also improved the logging that happens with "log enable dwarf lookups" is enabled to show when we find matches.
llvm-svn: 154352
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
correctly if the setter/getter were not present
in the debug information. The fixes are as follows:
- We not only look for the method by its full name,
but also look for automatically-generated methods
when searching for a selector in an Objective-C
interface. This is necessary to find accessors.
- Extract the getter and setter name from the
DW_TAG_APPLE_Property declaration in the DWARF
if they are present; generate them if not.
llvm-svn: 154067
|
| |
|
|
| |
llvm-svn: 153946
|
| |
|
|
| |
llvm-svn: 153940
|
| |
|
|
|
|
| |
Fixed an issue where there were more than one way to get a CompileUnitSP created when using SymbolFileDWARF with SymbolFileDWARFDebugMap. This led to an assertion that would fire under certain conditions. Now there is only one way to create the compile unit and it will "do the right thing".
llvm-svn: 153908
|
| |
|
|
|
|
|
|
|
|
| |
enabled using:
(lldb) log enable --verbose lldb completion
This will print out backtraces for all type completion calls which will help us verify that we don't ever complete a type when we don't need to.
llvm-svn: 153787
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed an issue that could cause circular type parsing that will assert and kill LLDB.
Prior to this fix the DWARF parser would always create class types and not start their definitions (for both C++ and ObjC classes) until we were asked to complete the class later. When we had cases like:
class A
{
class B
{
};
};
We would alway try to complete A before specifying "A" as the decl context for B. Turns out we can just start the definition and still not complete the class since we can check the TagDecl::isCompleteDefinition() function. This only works for C++ types. This means we will not be pulling in the full definition of parent classes all the time and should help with our memory consumption and also reduce the amount of debug info we have to parse.
I also reduced redundant code that was checking in a lldb::clang_type_t was a possible C++ dynamic type since it was still completing the type, just to see if it was dynamic. This was fixed in another function that was checking for a type being dynamic as an ObjC or a C++ type, but there was dedicated fucntion for C++ that we missed.
llvm-svn: 153713
|
| |
|
|
|
|
|
|
|
|
| |
Symbol files (dSYM files on darwin) can now be specified during program execution:
(lldb) target symbols add /path/to/symfile/a.out.dSYM/Contents/Resources/DWARF/a.out
This command can be used when you have a debug session in progress and want to add symbols to get better debug info fidelity.
llvm-svn: 153693
|
| |
|
|
|
|
|
|
|
|
| |
for unbacked properties. We support two variants:
one in which the getter/setter are provided by
selector ("mySetter:") and one in which the
getter/setter are provided by signature
("-[MyClass mySetter:]").
llvm-svn: 153675
|
| |
|
|
|
|
|
|
|
| |
1 - sections only get a valid VM size if they have SHF_ALLOC in the section flags
2 - symbol names are marked as mangled if they start with "_Z"
Also fixed the DWARF parser to correctly use the section file size when extracting the DWARF.
llvm-svn: 153496
|
| |
|
|
|
|
|
|
|
|
| |
Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not).
This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method.
This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB.
llvm-svn: 153482
|
| |
|
|
|
|
|
| |
if it's there and we may not have a cached die yet. This
fixes a bunch of false positives on "die has no decl".
llvm-svn: 153417
|
| |
|
|
|
|
|
|
| |
We now reject binaries built with LTO and print
an error, rather than crashing later while trying
to parse them.
llvm-svn: 153361
|
| |
|
|
|
|
|
|
|
|
| |
Fixed a case where the source path remappings on the module were too expensive to
use when we try to verify (stat the file system) that the remapped path points to
a valid file. Now we will use the lldb_private::Module path remappings (if any) when
parsing the debug info without verifying that the paths exist so we don't slow down
line table parsing speeds.
llvm-svn: 153059
|
| |
|
|
|
|
| |
Use the metadata in the dSYM bundle Info.plist to remap source paths when they keys are available.
llvm-svn: 152836
|
| |
|
|
|
|
|
|
|
|
| |
http://llvm.org/bugs/show_bug.cgi?id=12232
Fixed a case where a missing "break" in a switch statement could cause an assertion to fire and kill the debug session.
The fix was derived from the findings of Andrea Bigagli, thanks Andrea.
llvm-svn: 152741
|
| |
|
|
|
|
|
| |
Prepare LLDB to be built with C++11 by hiding all accesses to std::tr1 behind
macros that allows us to easily compile for either C++.
llvm-svn: 152698
|
| |
|
|
|
|
|
|
|
|
|
| |
This fix really needed to happen as a previous fix I had submitted for
calculating symbol sizes made many symbols appear to have zero size since
the function that was calculating the symbol size was calling another function
that would cause the calculation to happen again. This resulted in some symbols
having zero size when they shouldn't. This could then cause infinite stack
traces and many other side affects.
llvm-svn: 152244
|
| |
|
|
|
|
| |
<rdar://problem/10720345> "break set -n" name matching should only match at namespace boundaries
llvm-svn: 151876
|
| |
|
|
|
|
|
|
|
| |
so that the expression parser can look up members
of anonymous structs correctly. This meant creating
all the proper IndirectFieldDecls in each Record
after it has been completely populated with members.
llvm-svn: 151868
|
| |
|
|
|
|
| |
Don't try and unique anonymous struct/union/class types.
llvm-svn: 151863
|
| |
|
|
|
|
|
|
| |
startDefinition() ... endDefinition() block,
preventing crashes where the byte size of a
not-yet-complete type was being computed.
llvm-svn: 151546
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I started work on being able to add symbol files after a debug session
had started with a new "target symfile add" command and quickly ran into
problems with stale Address objects in breakpoint locations that had
lldb_private::Section pointers into modules that had been removed or
replaced. This also let to grabbing stale modules from those sections.
So I needed to thread harded the Address, Section and related objects.
To do this I modified the ModuleChild class to now require a ModuleSP
on initialization so that a weak reference can created. I also changed
all places that were handing out "Section *" to have them hand out SectionSP.
All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild
so all of the find plug-in, static creation function and constructors now
require ModuleSP references instead of Module *.
Address objects now have weak references to their sections which can
safely go stale when a module gets destructed.
This checkin doesn't complete the "target symfile add" command, but it
does get us a lot clioser to being able to do such things without a high
risk of crashing or memory corruption.
llvm-svn: 151336
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Objective-C classes. This allows LLDB to find
ivars declared in class extensions in modules other
than where the debugger is currently stopped (we
already supported this when the debugger was
stopped in the same module as the definition).
This involved the following main changes:
- The ObjCLanguageRuntime now knows how to hunt
for the authoritative version of an Objective-C
type. It looks for the symbol indicating a
definition, and then gets the type from the
module containing that symbol.
- ValueObjects now report their type with a
potential override, and the override is set if
the type of the ValueObject is an Objective-C
class or pointer type that is defined somewhere
other than the original reported type. This
means that "frame variable" will always use the
complete type if one is available.
- The ClangASTSource now looks for the complete
type when looking for ivars. This means that
"expr" will always use the complete type if one
is available.
- I added a testcase that verifies that both
"frame variable" and "expr" work.
llvm-svn: 151214
|
| |
|
|
| |
llvm-svn: 151202
|
| |
|
|
|
|
| |
Also add SB API's to set this callback, and to enable the log channels.
llvm-svn: 151018
|
| |
|
|
|
|
|
| |
anonymous types to each other unless they have
the same byte_size.
llvm-svn: 150422
|
| |
|
|
|
|
|
|
|
| |
indicate whether inline functions are desired.
This allows the expression parser, for instance,
to filter out inlined functions when looking for
functions it can call.
llvm-svn: 150279
|
| |
|
|
|
|
|
| |
by GetClangDeclContextContainingDIE, for better
debuggability.
llvm-svn: 150211
|
| |
|
|
|
|
|
|
| |
enable us to track the depth of parsing and what is being parsed. This
helps when trying to track down difficult type parsing issues and is only
enabled in non-production builds.
llvm-svn: 150203
|
| |
|
|
|
|
|
|
| |
for types that can be uniqued to the given type.
This is especially helpful when types are missing
file and line information.
llvm-svn: 150004
|
| |
|
|
|
|
| |
code. Removing these.
llvm-svn: 149903
|
| |
|
|
|
|
|
|
| |
working, but not functions). I need to check on a few things to make sure
I am registering everything correctly in the right order and in the right
contexts.
llvm-svn: 149858
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interface (.i) files for each class.
Changed the FindFunction class from:
uint32_t
SBTarget::FindFunctions (const char *name,
uint32_t name_type_mask,
bool append,
lldb::SBSymbolContextList& sc_list)
uint32_t
SBModule::FindFunctions (const char *name,
uint32_t name_type_mask,
bool append,
lldb::SBSymbolContextList& sc_list)
To:
lldb::SBSymbolContextList
SBTarget::FindFunctions (const char *name,
uint32_t name_type_mask = lldb::eFunctionNameTypeAny);
lldb::SBSymbolContextList
SBModule::FindFunctions (const char *name,
uint32_t name_type_mask = lldb::eFunctionNameTypeAny);
This makes the API easier to use from python. Also added the ability to
append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList.
Exposed properties for lldb.SBSymbolContextList in python:
lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list
lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list
lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list
lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list
lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list
lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list
This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...)
and then the result can be used to extract the desired information:
sc_list = lldb.target.FindFunctions("erase")
for function in sc_list.functions:
print function
for symbol in sc_list.symbols:
print symbol
Exposed properties for the lldb.SBSymbolContext objects in python:
lldb.SBSymbolContext.module => lldb.SBModule
lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit
lldb.SBSymbolContext.function => lldb.SBFunction
lldb.SBSymbolContext.block => lldb.SBBlock
lldb.SBSymbolContext.line_entry => lldb.SBLineEntry
lldb.SBSymbolContext.symbol => lldb.SBSymbol
Exposed properties for the lldb.SBBlock objects in python:
lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains
lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block
lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block
lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column
lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents
lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block)
lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned
lldb.SBBlock.ranges => an array or all address ranges for this block
lldb.SBBlock.num_ranges => the number of address ranges for this blcok
SBFunction objects can now get the SBType and the SBBlock that represents the
top scope of the function.
SBBlock objects can now get the variable list from the current block. The value
list returned allows varaibles to be viewed prior with no process if code
wants to check the variables in a function. There are two ways to get a variable
list from a SBBlock:
lldb::SBValueList
SBBlock::GetVariables (lldb::SBFrame& frame,
bool arguments,
bool locals,
bool statics,
lldb::DynamicValueType use_dynamic);
lldb::SBValueList
SBBlock::GetVariables (lldb::SBTarget& target,
bool arguments,
bool locals,
bool statics);
When a SBFrame is used, the values returned will be locked down to the frame
and the values will be evaluated in the context of that frame.
When a SBTarget is used, global an static variables can be viewed without a
running process.
llvm-svn: 149853
|
| |
|
|
|
|
| |
for types and comparing decl context matches.
llvm-svn: 149812
|
| |
|
|
|
|
| |
in the DWARF plug-in.
llvm-svn: 149811
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed "target modules list" (aliased to "image list") to output more information
by default. Modified the "target modules list" to have a few new options:
"--header" or "-h" => show the image header address
"--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library)
Removed the "--symfile-basename" or "-S" option, and repurposed it to
"--symfile-unique" "-S" which will show the symbol file if it differs from
the executable file.
ObjectFile's can now be loaded from memory for cases where we don't have the
files cached locally in an SDK or net mounted root. ObjectFileMachO can now
read mach files from memory.
Moved the section data reading code into the ObjectFile so that the object
file can get the section data from Process memory if the file is only in
memory.
lldb_private::Module can now load its object file in a target with a rigid
slide (very common operation for most dynamic linkers) by using:
bool
Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed)
lldb::SBModule() now has a new constructor in the public interface:
SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr);
This will find an appropriate ObjectFile plug-in to load an image from memory
where the object file header is at "header_addr".
llvm-svn: 149804
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM/Clang. This brings in several fixes, including:
- Improvements in the Just-In-Time compiler's
allocation of memory: the JIT now allocates
memory in chunks of sections, improving its
ability to generate relocations. I have
revamped the RecordingMemoryManager to reflect
these changes, as well as to get the memory
allocation and data copying out fo the
ClangExpressionParser code. Jim Grosbach wrote
the updates to the JIT on the LLVM side.
- A new ExternalASTSource interface to allow LLDB to
report accurate structure layout information to
Clang. Previously we could only report the sizes
of fields, not their offsets. This meant that if
data structures included field alignment
directives, we could not communicate the necessary
alignment to Clang and accesses to the data would
fail. Now we can (and I have update the relevant
test case). Thanks to Doug Gregor for implementing
the Clang side of this fix.
- The way Objective-C interfaces are completed by
Clang has been made consistent with RecordDecls;
with help from Doug Gregor and Greg Clayton I have
ensured that this still works.
- I have eliminated all local LLVM and Clang patches,
committing the ones that are still relevant to LLVM
and Clang as needed.
I have tested the changes extensively locally, but
please let me know if they cause any trouble for you.
llvm-svn: 149775
|
| |
|
|
|
|
| |
pointer.
llvm-svn: 149609
|
