mostly related to management of the stack frame
for the interpreter.

  - First, if the expression can be interpreted,
    allocate the stack frame in the target process
    (to make sure pointers are valid) but only
    read/write to the copy in the host's memory.

  - Second, keep the memory allocations for the
    stack frame and the materialized struct as
    member variables of ClangUserExpression.  This
    avoids memory allocations and deallocations
    each time the expression runs.

<rdar://problem/13043685>

llvm-svn: 180664

null pointer.

<rdar://problem/13745684>

llvm-svn: 180663

Synthetic children provider for NSOrderedSet

llvm-svn: 180655

presence of malformed class types.

<rdar://problem/13740646>

llvm-svn: 180645

This fixes a problem on Linux where allocated memory would get overun in some use cases (ie. in TestExprs2.py).

llvm-svn: 180614

llvm-svn: 180612

llvm-svn: 180588

Patch by Ashok Thirumurthi.

llvm-svn: 180581

- Adds unique enums for ymm registers to the ABI and the POSIX register context.
- Reworks the register context data structures to support a union of FXSAVE and XSAVE
--- Allows the same code base to deal with the FPU independent of the availability of AVX.
- Determine if AVX is supported by attempting to read XSAVE using ptrace.
--- Support an extended register set for avx registers if available.
- Provide a mechanism to assemble/parse register halves into a single ymm buffer for use with RegisterValue.
--- Reworked Read/WriteRegister routines to read/write/parse ymm registers.

Adds tests for ymm register write with read-back, and expressions involving ymm registers.
- Tests vary depending on the availability of an avx register set.

Thanks to Daniel and Matt for their reviews.

llvm-svn: 180572

interpreter.  They are a legacy from when the IR
interpreter didn't work with materialized values
but rather got values directly from
ClangExpressionDeclMap.

Also updated the #includes for IRInterpreter
accordingly.

llvm-svn: 180565

disabled.

llvm-svn: 180563

In Process::ProcessEventData::DoOnRemoval, we need to handle the case where NO thread has a stop reason
specially, and make sure we stop.  This shouldn't happen, but if it does, the user will probably want to
see it.

<rdar://problem/13273125>

llvm-svn: 180244

llvm-svn: 180243

llvm-svn: 180242

If a register is in a ValueObject, be sure to print its children if it is a vector type.

llvm-svn: 180237

Don't print the type if there is none and don't print "<invalid type>". ValueObjects can be register sets and register groups and dumping those with:

(lldb) script print frame.GetRegisters()

llvm-svn: 180236

Don't crash if we try to interpret the IR (incorrectly in this case) and can't handle the size. This came from trying to do:

(lldb) p typedef float __attribute__((ext_vector_type(8))) __ext_vector_float8; (__ext_vector_float8)$ymm0

llvm-svn: 180235

Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)).

There is a new static ObjectFile function you can call:

size_t
ObjectFile::GetModuleSpecifications (const FileSpec &file,
                                     lldb::offset_t file_offset,
                                     ModuleSpecList &specs)

This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question).

This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info.

llvm-svn: 180224

See: http://stackoverflow.com/questions/16166897/c-how-to-obtain-address-of-stdvector-object-in-lldb-xcode
The user was trying to obtain the address-of an std::vector and the experience was more painful than necessary because data formatters were kicking in for vector* objects
We got this right for libc++ - we should get it right for libstdc++ too

llvm-svn: 180219

“plugin load” tries to be more helpful when it fails to load a plugin

llvm-svn: 180218

sent to "super".

<rdar://problem/13042260>

llvm-svn: 180217

(normally undefined) as indicating a breakpoint hit, in addition
to the normal (EXC_BREAKPOINT, EXC_ARM_BREAKPOINT) pair.
<rdar://problem/13730366> 

llvm-svn: 180216

<rdar://problem/12977827>

llvm-svn: 180215

llvm-svn: 180212

out of the runtime.  This allows calling static methods
on classes whose symbols have been stripped out of the
binary.

<rdar://problem/12042992>

llvm-svn: 180210

Pass the user set target.env-vars when launching through a terminal.

llvm-svn: 180201

llvm-svn: 180199

not find multiple functions with the same name but
different types.  Now we keep track of what types
we've already reported for a function and only elide
functions if we've already reported a conflicting
one.

Also added a test case.

<rdar://problem/11367837>

llvm-svn: 180167

llvm-svn: 180156

Fixed LLDB to be able to correctly parse template parameters that have no name and no type. This can be triggered by the following LLVM/Clang code:

template <typename T, typename = void>
class SmallVectorTemplateCommon : public SmallVectorBase {

The “typename = void” was emitting DWARF with an empty DW_AT_name and no DW_AT_type. We now correctly infer that no DW_AT_type means “void” and that an empty name is ok.

This means you can now call functions on things that inherit from SmallVectorTemplateCommon.

llvm-svn: 180155

llvm-svn: 180154

Be sure to print out the fully mangled name when we are unable to find a function to call so we can easily look for this symbol if needed.

llvm-svn: 180151

llvm-svn: 180148

- Includes tests that write, read and verify vector register content.
            
Reviewed by: Daniel Malea

llvm-svn: 180143

llvm-svn: 180142

The new ReadStringFromMemory() API does not work correctly with NSStrings that have an explicit length and no NULL terminator
This checkin reverts NSString to the old behavior when appropriate, and cleans up the syntax to call the UTF Reader&Dumper function
Incidentally, add a "-d" command-line flag to redo.py with the same semantics as "-d" in dotest.py

llvm-svn: 180141

llvm-svn: 180117

Patch by Yacine Belkadi!

When __GLIBC__ is defined, optind gets initialized to 0. So for the first parsed
option, parse_start is 0, too. If this option has no argument (Like "--continue"
of "process attach"), then the position stored is 0, instead of 1. This prevents
the completion later on in Options::HandleOptionCompletion() because the opt_pos
doesn't match the cursor_index.

Fix that by getting the option's position from the value of optind, as it's done
for the other types of options.

Re-enable test_process_attach_dash_dash_con() on Linux.

No regressions detected on Mac OS X (in TestCompletion.py)

llvm-svn: 180114

- Includes tests that write, verify and restore floating-point register content using SBFrame.

Reviewed by: Daniel Malea

llvm-svn: 180111

unwind instructions for a function/symbol which contains that
address.

Update the unwind_diagnose.py script to use this instead of doing
image show-unwind by name to avoid cases where there are multiple
name definitions.

llvm-svn: 180079