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

Making sure that CF*{Array|Dictionary}Ref provide synthetic children correctly.

llvm-svn: 180074

llvm-svn: 180071

Removing these namespace { ... } declarations (but still keeping the helper *Impl objects outside of namespace lldb proper)

llvm-svn: 180067

llvm-svn: 180061

- avoid deadlocks if Broadcaster::SignUpListenersForBroadcaster and
  Listener::StartListeningForEventSpec are both called concurrently

llvm-svn: 180050

This fixes function type resolution for C functions when requesting full function names.

llvm-svn: 180048

llvm-svn: 180047

Providing a dummy RegisterContext to secure against faulty Python OS plugins that do not return a valid RegisterContext
The RegisterContextDummy exports a PC with a constant 0xFFFFFFFFFFFFFFFF value

llvm-svn: 180033

Do this until we are able to resolve these symbols to their actual implementations without needing runtime support.

llvm-svn: 180029

and persistent variables so that they are not
treated as remaining in the target process (i.e.,
having live data) when the process does not allow
persistent allocations (e.g., when there is no
process or in the case of kernel core files).

llvm-svn: 179919