llvm-svn: 161719

llvm-svn: 161718

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

<rdar://problem/11274012>

llvm-svn: 161704

llvm-svn: 161696

llvm-svn: 161684

an invalid register.

<rdar://problem/12065366>

llvm-svn: 161679

Forgot to check in this file.  Oops!

llvm-svn: 161639

Add 'watchpoint command add/delete/list' to lldb, plus two .py test files.

llvm-svn: 161638

Added back member initialization for m_batch_command_mode, which was most likely removed accidentally a while back.
The consequence occurred recently probably due to our swicth to build with c++11.
This fixed 3 test failures.

llvm-svn: 161625

<rdar://problem/11578397> Adding a new --summary-string option for the frame variable command which allows the user to provide a summary string with which he wants to display the variables without having to make a named summary first

llvm-svn: 161623

<rdar://problem/11703715>

llvm-svn: 161611

<rdar://problem/10449092> Adding a new uppercase hex format specifier. This commit also changes the short names for formats so that uppercase hex can be 'X', which was previously assigned to hex float. hex float now has no short name.

llvm-svn: 161606

the expression returns nothing.  There is now a
setting, "notify-void."  When the user enables
that setting, lldb prints (void) if an expression's
result is void.  Otherwise, lldb is silent.

<rdar://problem/11225150>

llvm-svn: 161600

llvm-svn: 161592

libc++.  We also no longer use the GNU extensions
to C++ and C (we didn't use them anyway).

This also means that the LLVM we use must be
built with the new libc++.

I will commit llvm.zip next.

<rdar://problem/11930775>

llvm-svn: 161562

llvm-svn: 161560

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

an expected failure.

llvm-svn: 161556

<rdar://problem/12061386> Fixing data-formatter-cpp test case - previous version had an unfortunate dependency on the value of uninitialized memory

llvm-svn: 161555

them as expected failures until they are fixed.

llvm-svn: 161547

Fixed the delay that was happening when quitting lldb from the command line. We weren't initializing the command pipes when constructing a ConnectionFileDescriptor with a file descriptor.

llvm-svn: 161533

suppress all non-error output from the "expression"
command.

<rdar://problem/11225150>

llvm-svn: 161502

llvm-svn: 161493

llvm-svn: 161492

<rdar://problem/11975483> Removing user-visible references to 'dict' as a parameter name for Python summary-generating functions since it is a Python keyword.

llvm-svn: 161467

for people used to the GDB command.

<rdar://problem/12052072>

llvm-svn: 161466

Added the ability to set the architecture from two numbers that represent the mach-o CPU type and subtype in the format "%u-%u" or "%u.%u". This can of course be followed by vendor and OS.

llvm-svn: 161465

llvm-svn: 161464

llvm-svn: 161420

llvm-svn: 161419

Fixing an issue where ValueObject::GetPointeeData() would not work correctly for file addresses when fetching items other than the 0-th

llvm-svn: 161384

require an AddressClass, which is useless at this
point since it already knows the distinction between
32-bit Thumb opcodes and 32-bit ARM opcodes.

llvm-svn: 161382

Fixed an error in the thumb opcode encoding. We need the 32 bit thumb instructions to be encoded as a 32 bit value for the EmulateARM code.

llvm-svn: 161381

llvm-svn: 161374

llvm-svn: 161360

Use the built in demangler for Apple builds for now which has needed demangling fixes, and make the cxa_demangle.cpp use rtti in the Xcode project settings as it requires it be enabled.

llvm-svn: 161323

Pull in cxa_demangle.cpp/.h from llvm's libcxxabi project.  Change the namespace to lldb_cxxabiv1 for the time being.
Mangled.cpp is not wired in to call it yet.

llvm-svn: 161293

<rdar://problem/12027563> Making sure that some class of stop-hook commands that involve po'ing objects do not cause an endless recursion

llvm-svn: 161271