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

access to 'z' where 'z' was not in scope.

llvm-svn: 180662

Synthetic children provider for NSOrderedSet

llvm-svn: 180655

presence of malformed class types.

<rdar://problem/13740646>

llvm-svn: 180645

llvm-svn: 180636

Mark tests as expected fail for Linux due to not being able to call/print c++ demangled functions in the global namespace (bugzilla 15854).

llvm-svn: 180623

llvm-svn: 180621

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: 180613

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

llvm-svn: 180223

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: 180158

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: 180149