llvm-svn: 174579

Fixed an bug found by running LLDB with the address sanitizer! We were accessing one past the end of the buffer.

llvm-svn: 174578

llvm-svn: 174558

if it encountered bad debug information.  This
debug information had an Objective-C method whose
selector disagreed with the true number of arguments
to that method.

<rdar://problem/12992864>

llvm-svn: 174557

llvm-svn: 174556

lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules.

LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required.

Added a new logging channel for "lldb" called "mmap" to help track future regressions.

Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to.

The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info.

llvm-svn: 174524

- resolves errors in cases that run the lldb CLI utility

llvm-svn: 174522

llvm-svn: 174520

Patch by Abid Hafiz!

llvm-svn: 174519

The first part of the fix for having LLDB handle LTO debugging when the DWARF is in the .o files. This part separates the object file's modules into a separate cache map that maps unique C strings for the N_OSO path to the ModuleSP since one object file might be mentioned more than once in LTO binaries.

llvm-svn: 174476

Fixed the TestSourceManager.py test case to not fail. It was using the "list" alias which has now been turned into a regex command that mimics the GDB equivalent. Changed "list" to "source list" to get around this problem.

llvm-svn: 174474

function stub routine addresses from an in-memory-only
MachO object file.  This was the only remaining part of
ParseSymtab() that was assuming a file exists.
<rdar://problem/13139585> 

llvm-svn: 174455

llvm-svn: 174437

Removed asserts and replaced them with conditional code and appropriate errors that prompt for a bug to be filed.

llvm-svn: 174420

that the original issue has been fixed by r174222.

llvm-svn: 174334

Synthetic children and summary for std::vector<bool> (for both libcxx and libstdcpp).
std::vector<bool> is a special case and is custom-implemented to be a vector of bits, which means we failed to handle it with the standard std::vector<T> formatter.
This checkin provides custom formatters that work correctly

llvm-svn: 174333

fixes crash of the form

% lldb
(lldb) target symbols add /tmp/symbols.dSYM
(lldb) Killed: 9

<rdar://problem/13139481> 

llvm-svn: 174267

set logfile=<path>
set logmask=<num>

But this opens the door for us to do much more.

llvm-svn: 174258

It is better practice and, also, it is not clear whether std::auto_ptr<> is smart enough to know about delete[] vs. delete

llvm-svn: 174236

Added a regular expression command called "_regexp-list" which mimics the GDB "line" command in the following forms:

LINENUM, to list around that line in current file,
FILE:LINENUM, to list around that line in that file,
FUNCTION, to list around beginning of that function,
*ADDRESS, to list around the line containing that address.
ADDRESS, same as above, but don't require a '*' as long as ADDRESS is hex

llvm-svn: 174233

Added the ability to send monitor command to the remote GDB server with "process plugin packet monitor".

llvm-svn: 174231

Class global variables were not being linked correctly when debugging with DWARF in .o files.

llvm-svn: 174227

Fix in loading mach files from memory when using DynamicLoaderMacOSXDYLD.

Removed the uuid mismatch warning that could be spit out and any time during debugging and removed the test case that was looking for that. Currently the "add-dsym" or "target symbols add" command will report an error when the UUID's don't match.

Be more careful when checking and resolving section + offset addresses to make sure none of the base addresses are invalid.

llvm-svn: 174222

be "signed char" not "int".

<rdar://problem/13131126>

llvm-svn: 174209

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

llvm-svn: 174141

A bit of cleanup in the heap module. 

llvm-svn: 174129

llvm-svn: 174128

llvm-svn: 174127

Add "thread return -x" to unwind the innermost user called expression (if you happen to have stopped in it due to a crash.)
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

<rdar://problem/13121442>

llvm-svn: 174082

llvm-svn: 174074

Added the ability to search segments for data. Currently __TEXT, __LINKEDIT and __PAGEZERO are excluded. 

Added many more cleanups to the output.

llvm-svn: 174045

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

setting is working correctly now; remove the #if 0's around its
use.

llvm-svn: 173982

The vtable pointer field is not necessarily a pointer and hence cannot be used for validation

llvm-svn: 173947

llvm-svn: 173937

llvm-svn: 173935

handling that was probably the source of the settings problem.  Need to verify that
it's working correctly tomorrow though.

llvm-svn: 173894

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