llvm-svn: 167236

launch process (null)" because we changed argv while doing argument
parsing.

llvm-svn: 167202

There seems to be some odd corner case where we shut down the ProcessGDBRemote, but we haven't managed to shut down the async thread.  That causes the ProcessGDBRemote::AsyncThread to crash when it wakes up.  So I changed StartAsyncThread and StopAsyncThread to be callable multiple times (only the first one does anything) so that we can just shut it down unequivocally in the ProcessGDBRemote destructor.

<rdar://problem/12602981>

llvm-svn: 167197

Switch from using KERN_PROCARGS2 to get the path to the executed process to proc_pidpath.  The former was flakey, and the whole point of libproc is to protect us from potential flakiness at that level...

<rdar://problem/12594781>

llvm-svn: 167194

llvm-svn: 167183

llvm-svn: 167182

llvm-svn: 167179

llvm-svn: 167175

llvm-svn: 167171

llvm-svn: 167168

Carlo Kok found an issue where default parameters were causing the wrong argument to be passed. I got rid of the default args so we don't run into this.

llvm-svn: 167167

Patch for issue found by Carlo Kok. Fixed a type issue where an ';' was incorrectly following an if statement. There actually isn't a need for the if statement, so it was removed.

llvm-svn: 167160

that confused external clients.

<rdar://problem/12599528>

llvm-svn: 167097

Headers build phase.

llvm-svn: 167096

CXXMethodDecl but tried to manipulate it
anyway.

<rdar://problem/12601996>

llvm-svn: 167095

so it is recognized correctly.  The second patch needed for <rdar://problem/10652166>.

llvm-svn: 167094

<rdar://problem/12586188> Make ImportError a special case for "command script import", such that the error message for the exception becomes the error for the entire import operation
and silence the backtrace printout

In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly
instead of having the default behavior

llvm-svn: 167067

RegisterContextKDP_i386 was not correctly writing registers due to missing "virtual" keywords. Added the virtual keywords and made the functions pure virtual to ensure subclasses can't get away without implementing these functions.

llvm-svn: 167066

llvm-svn: 167065

the containing class so that direct ivar access will work in the expression parser.

<rdar://problem/9797999>

llvm-svn: 167061

llvm-svn: 167060

"~rc" via getpwnam() instead of doing tilde expansion and doing soft-link
dereferencing via realpath() - if we're pointing to a softlink, leave it
as-is.  
<rdar://problem/12597698>

llvm-svn: 167052

The attached patch adds eValueTypeVector to lldb_private::Value.  The nested struct Vector is patterned after RegisterValue::m_data.buffer.  This change to Value allows ClangExpressionDeclMap::LookupDecl to return vector register data for consumption by InterpreterStackFrame::ResolveValue.  Note that ResolveValue was tweaked slightly to allocate enough memory for vector registers.
 
An immediate result of this patch is that "expr $xmm0" generates the same results on Linux as on the Mac, which is good enough for TestRegisters.py.  In addition, the log of m_memory.PrintData(data_region.m_base, data_region.m_extent) shows that the register content has been resolved successfully.  On the other hand, the output is glaringly empty:
    runCmd: expr $xmm0
    output: (unsigned char __attribute__((ext_vector_type(16)))) $0 = {}
    Expecting sub string: vector_type
    Matched

llvm-svn: 167033

Replace printf with result.Printf, so that the plugin shows its output with any configuration of the LLDB I/O streams (esp. useful in graphic environments such as Xcode)

llvm-svn: 167030

llvm-svn: 167028

This patch switches support on Linux from JIT to MCJIT.

llvm-svn: 167026

llvm-svn: 167025

llvm-svn: 167024

     bool
     SBType::IsFunctionType ();

     lldb::SBType
     SBType::GetFunctionReturnType ();
 
     lldb::SBTypeList
     SBType::GetFunctionArgumentTypes ();

llvm-svn: 167023

llvm-svn: 167019

There should be no functional changes as SBData creation functions already checked for NULL regardless of size - but it ensures consistency

llvm-svn: 166978

<rdar://problem/11449953> Change Debugger::SetOutputFileHandle() so that it does not automatically initialize the script interpreter in order to transfer its output file handle to it
This should delay initialization of Python until strictly necessary and speed-up debugger startup
Also, convert formatters for SEL and BOOL ObjC data-types from Python to C++, in order to reap more performance benefits from the above changes

llvm-svn: 166967

I tracked down a leak that could happen when detaching from a process where the lldb_private::Process objects would stay around forever. This was caused by a eStateDetached event that was queued up on the lldb_private::Process private state thread listener. Since process events contain shared pointers to the process, this is dangerous if they don't get consume or cleared as having the lldb_private::Process class contain a collection of things that have a shared pointer to yourself is obviously bad. 

To fix this I modified the Process::Finalize() function to clear this list. The actual thing that was holding onto the ModuleSP and thus the static archive, was a stack frame. Since the process wasn't going away, it still had thread objects and they still had frames. I modified the Thread::Destroy() to clear the stack frames to ensure this further doesn't happen.

llvm-svn: 166964

llvm-svn: 166959

llvm-svn: 166950

so it could hold this information, and then used it to look up unfound names in the object pointer
if it exists.  This gets "frame var" to work for unqualified references to ivars captured in blocks.
But the expression parser is ignoring this information still.

llvm-svn: 166860

the raw exception.

llvm-svn: 166859

Removing the IsDynamic() and GetStaticValue() calls, so that they will default to the base class behavior:
 - non-dynamic
 - itself as the static value
This is in contrast with the previous behavior which could be confusing and could potentially cause issues when using those objects

llvm-svn: 166857

- Only read the statically-defined isa table in the
  shared cache once.  Only the dynamically-constructed
  isa table can change.

- Ignore the statically-defined isa table if its
  version isn't what we expect.

llvm-svn: 166856

llvm-svn: 166839