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

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

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

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

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

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

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

llvm-svn: 173982

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

- remove nullptr from initialization of shared_ptrs

llvm-svn: 173870

llvm-svn: 173865

llvm-svn: 173864

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

llvm-svn: 173840

wchar_t causes problem with certain compilers. Removing it for now.

llvm-svn: 173823

llvm-svn: 173757

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