support reporting "this" as a templated class. The
expression parser wraps expressions in C++ methods
as methods with the signature
$__lldb_class::$__lldb_expr(...)
and previously responded to clang's queries about
$__lldb_class with the type of *this. This didn't
work if *this was a ClassTemplateSpecializationDecl
because ClassTemplateSpecializationDecls can't be
the result of simple name queries.
Instead what we do now is respond that $__lldb_class
is a typedef and that the target of the typedef is
the (potentially templated) type of *this. That is
much more robust.
Thanks to John McCall for key insights.
<rdar://problem/10987183>
llvm-svn: 174153
Make the message when you hit an crash while evaluating an expression a little clearer, and mention "thread return -x".
rdar://problem/13110464
llvm-svn: 174095
C++11 lambdas that don't capture anything can be used as static callback functions!
Heavily modified this python module to be able to not require a dylib in order to traverse the heap allocations.
Re-implemented the ptr_refs, objc_refs, malloc_info and cstr_refs to use complex expressions that use lambdas to do all static callback function work.
llvm-svn: 173989
Enhance lldb so it can search for a kernel in memory when attaching
to a remote system. Remove some of the code that was doing this
from ProcessMachCore and ProcessGDBRemote and put it in
DynamicLoaderDarwinKernel.
I've added a new setting, plugin.dynamic-loader.darwin-kernel.scan-type
which can be set to
none - for environments where reading random memory can cause a
device crash
basic - look at one fixed location in memory for a kernel load address,
plus the contents of that address
fast-scan - the default, tries "basic" and then looks for the kernel's
mach header near the current pc value when lldb connects
exhaustive-scan - on 32-bit targets, step through the entire range where
the kernel can be loaded, looking for the kernel binary
I don't have the setting set up correctly right now, I'm getting back unexpected
values from the Property system, but I'll figure that out tomorrow and fix.
Besides that, all of the different communication methods / types of kernels
appear to be working correctly with these changes.
llvm-svn: 173891
Cleaned up the objective C name parsing code to use a class.
Now breakpoints that are set by name that are objective C methods without the leading '+' or '-' will resolve. We do this by expanding all the objective C names for a given string. For example:
(lldb) b [MyString cStringUsingEncoding:]
Will set a breakpoint with multiple possible names:
-[MyString cStringUsingEncoding:]
+[MyString cStringUsingEncoding:]
Also if you have a category, it will strip the category and set a breakpoint in all variants:
(lldb) [MyString(my_category) cStringUsingEncoding:]
Will resolve to the following names:
-[MyString(my_category) cStringUsingEncoding:]
+[MyString(my_category) cStringUsingEncoding:]
-[MyString cStringUsingEncoding:]
+[MyString cStringUsingEncoding:]
Likewise when we have:
(lldb) b -[MyString(my_category) cStringUsingEncoding:]
It will resolve to two names:
-[MyString(my_category) cStringUsingEncoding:]
-[MyString cStringUsingEncoding:]
llvm-svn: 173858
Replacing the address argument type with address-expression in cases where StringToAddress() is used, and hence an expression can be passed where previously only a numeric address was allowed
This makes the documentation more clear and helps users discover that they can truly pass in an expression in these situations.
llvm-svn: 173753
Providing a compact display mode for "po" to use where the convenience variable name and the pointer value are both hidden.
This is for convenience when dealing with ObjC instances where the description often gets it right and the debugger-provided information is not useful to most people.
If you need either of these, "expr" will still show them.
llvm-svn: 173748
Flush the process when symbols are loaded/unloaded manually. This was going on in:
- "target modules load" command
- SBTarget::SetSectionLoadAddress(...)
- SBTarget::ClearSectionLoadAddress(...)
- SBTarget::SetModuleLoadAddress(...)
- SBTarget::ClearModuleLoadAddress(...)
llvm-svn: 173745
Data formatters now cache themselves.
This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval.
Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization.
The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime.
Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type.
Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose.
llvm-svn: 173728
Add the ability to give breakpoints a "kind" string, and have the StopInfoBreakpoint
print that in the brief description if set. Also print the kind - if set - in the breakpoint
listing.
Give kinds to a bunch of the internal breakpoints.
We were deleting the Mac OS X dynamic loader breakpoint as though the id we had stored away was
a breakpoint site ID, but in fact it was a breakpoint id, so we never actually deleted it. Fixed that.
llvm-svn: 173555
- set auto-confirm to false when running TestExprs (avoid hang when using API)
- set prompt-on-quit to false in test helper (avoid timeout when using lldb CLI)
llvm-svn: 173485
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
Change the GDBRemoteRegisterContext::AddRegister function to take
its RegisterInfo argument by value instead of using a reference -
it will modify the object and modifying the contents of the
g_register_infos table in GDBRemoteRegisterContext.cpp can cause a
crash the next time we step through it.
llvm-svn: 173406
- introduce new variable ARCHFLAG in make/Makefile.rules to switch between "-arch" on Mac and "-m" everywhere else
- update testcase makefiles to use LD_EXTRAS instead of LDFLAGS (the former interacts with Makefile.rules badly)
- special treatment for gcc 4.6: replace "-std=c++11" with "-std=c++0x" as the former is not handled correctly
- remove hardcoded "-arch" from test Makefile
This patch should not have any effect on lldb on Mac OS X.
llvm-svn: 173402
- PR 15038: missing wide char support on Linux
- PR 14600 - Exception state registers not supported on Linux
- PR 15039: SBProcess.GetSTDOUT() returns an empty buffer
- PR 15037: stop-hooks sometimes fail to fire on Linux
llvm-svn: 173363
Sean Callanan