| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
When uniquing classes against one another we can't depend on any or all of the artificial functions (default ctor, dtor, copy ctor, move ctor, etc) being in each definition. Now we treat those separately and handle those to the best of our ability.
llvm-svn: 167752
|
|
|
|
|
|
|
| |
- Add missing operator= definition for DelayedAddObjCClassProperty
- needed to be compatible with libstdc++ vector implementation
llvm-svn: 167747
|
|
|
|
|
|
|
|
|
| |
DynamicLoaderDarwinKernel::OSKextLoadedKextSummary::LoadImageUsingMemoryModule
where it assumed that a kernel had been found in memory, when that may not be
the case when we're attaching to a device early in the boot process.
<rdar://problem/12638140>
llvm-svn: 167564
|
|
|
|
|
|
|
|
|
|
| |
<rdar://problem/12153915> (partial fix)
Remove an assert and place an error message instead so we don't crash when we run into a type tag that we don't recognize. We will now emit a warning so that hopefully we can get a bug report that has example code that shows what we are missing.
Also fixed a case when trying to unique one type to another where we would confuse concrete instances of methods with their definitions and end up not correctly registering the types.
llvm-svn: 167557
|
|
|
|
| |
llvm-svn: 167473
|
|
|
|
|
|
|
|
| |
Unnamed bitfields cause struct layout problems
Synthesize unnamed bitfields when required. Most compilers don't mention unnamed bitfields in the DWARF, so we need to create them to keep clang happy with the types we create from the DWARF. We currently can't do this for ObjC since the DW_AT_bit_offset value for any direct ivars of ObjC classes as the values for these attributes are bogus. A bug has been filed on Clang to fix this, and another bug has been filed on LLDB to make sure we fix the DWARF parser once the clang fix is in by looking the the DW_AT_producer in the compile unit attributes and finding the compiler version and only enabling it for newer versions of clang.
llvm-svn: 167424
|
|
|
|
|
|
| |
LLDB now provides base class offsets (virtual and non virtual) to Clang's record layout. We previously were told this wasn't necessary, but it is when pragma pack gets involved.
llvm-svn: 167262
|
|
|
|
| |
llvm-svn: 167236
|
|
|
|
|
|
|
|
|
| |
CXXMethodDecl but tried to manipulate it
anyway.
<rdar://problem/12601996>
llvm-svn: 167095
|
|
|
|
| |
llvm-svn: 167060
|
|
|
|
| |
llvm-svn: 167024
|
|
|
|
|
|
|
|
|
|
| |
expanded the decl metadata
so it could hold this information, and then used it to look up unfound names in the object pointer
if it exists. This gets "frame var" to work for unqualified references to ivars captured in blocks.
But the expression parser is ignoring this information still.
llvm-svn: 166860
|
|
|
|
|
|
|
|
| |
of structures, and added a testcase.
<rdar://problem/12551591>
llvm-svn: 166450
|
|
|
|
|
|
|
|
|
|
|
| |
1 by the expression parser. We now correctly
report that they are of size 0. (C++ structs
are mandated to have nonzero size, and Clang marks
them as being 1 byte in size.)
<rdar://problem/12380800>
llvm-svn: 166256
|
|
|
|
| |
llvm-svn: 165808
|
|
|
|
| |
llvm-svn: 165441
|
|
|
|
|
|
| |
from a NULL ObjCInterfaceDecl.
llvm-svn: 165261
|
|
|
|
|
|
| |
the DWARF 4 specification.
llvm-svn: 164779
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
top-of-tree. Removed all local patches and llvm.zip.
The intent is that fron now on top-of-tree will
always build against LLVM/Clang top-of-tree, and
that problems building will be resolved as they
occur. Stable release branches of LLDB can be
constructed as needed and linked to specific release
branches of LLVM/Clang.
llvm-svn: 164563
|
|
|
|
|
|
| |
Some platforms don't support this modification.
llvm-svn: 164148
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
|
|
|
|
|
|
| |
Remember to copy the address byte size and the byte order when copying data into a DWARF location object, or things will go wrong.
llvm-svn: 161721
|
|
|
|
|
|
| |
reference into the debug info until test suite failures are resolved.
llvm-svn: 161720
|
|
|
|
|
|
| |
return bool.
llvm-svn: 161719
|
|
|
|
|
|
| |
Fixed an issue that could cause references the shared data for an object file to stay around longer than intended and could cause memory bloat when debugging multiple times.
llvm-svn: 161716
|
|
|
|
|
|
|
|
|
| |
and instead made us use implicit casts to bool.
This generated a warning in C++11.
<rdar://problem/11930775>
llvm-svn: 161559
|
|
|
|
|
|
|
|
| |
hash_multimap to unordered_multimap.
<rdar://problem/11930775>
llvm-svn: 161558
|
|
|
|
|
|
| |
that has bit rotted and isn't being used. Also cleaned up the API to the "lldb_private::Mangled" to always take "const ConstString &" arguments instead of both "const ConstString &" and "const char *".
llvm-svn: 160466
|
|
|
|
|
|
|
| |
single element. Also modified our struct test
case to test this.
llvm-svn: 160449
|
|
|
|
|
|
| |
Remove assertions and turn what used the be the assertion into a logged error with instructions on what to attach to a radar so we can track down why this is happening.
llvm-svn: 160392
|
|
|
|
| |
llvm-svn: 160338
|
|
|
|
|
|
| |
Fixed issues that could happen when the UUID doesn't change in a binary and old stale debug info could end up being used.
llvm-svn: 160145
|
|
|
|
|
|
|
|
| |
a NULL symbol file.
<rdar://problem/11795939>
llvm-svn: 159882
|
|
|
|
|
|
|
|
|
| |
didn't check if the two classes had the same number
of members.
<rdar://problem/11678873>
llvm-svn: 159880
|
|
|
|
| |
llvm-svn: 159685
|
|
|
|
|
|
|
|
|
|
|
| |
a cache of address ranges for child sections,
accelerating lookups. This cache is built during
object file loading, and is then set in stone once
the object files are done loading. (In Debug builds,
we ensure that the cache is never invalidated after
that.)
llvm-svn: 158188
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that automatically generated setters/getters only
get added to a class after explicitly declared (or
synthesized) getters/setters had the chance to be
added. This eliminates conflicts creating errors
of the form:
error: instance method '...' has incompatible result
types in different translation units ('X *' vs. 'id')
llvm-svn: 157956
|
|
|
|
|
|
| |
Fixed an issue with the current type being set to DIE_IS_BEING_PARSED in the m_die_to_type map by making sure the type pointer is valid.
llvm-svn: 157836
|
|
|
|
| |
llvm-svn: 157328
|
|
|
|
|
|
|
|
| |
(actually, mainly just hooked up support that was already
there). Added a test case, although it's expected to fail
right now unless you're using top-of-tree LLVM.
llvm-svn: 157220
|
|
|
|
|
|
| |
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
|