<rdar://problem/11961650> 

Update the debugserver "qProcessInfo" implementation to return the
cpu type, cpu subtype, OS and vendor information just like qHostInfo
does so lldb can create an ArchSpec based on the returned values.

Add a new GetProcessArchitecture to GDBRemoteCommunicationClient akin
to GetHostArchitecture.  If the qProcessInfo packet is supported,
GetProcessArchitecture will return the cpu type / subtype of the 
process -- e.g. a 32-bit user process running on a 64-bit x86_64 Mac
system. 

Have ProcessGDBRemote set the Target's architecture based on the 
GetProcessArchitecture when we've completed an attach/launch/connect.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170491 91177308-0d34-0410-b5e6-96231b3b80d8
Test suite cleanup for Linux: mark test cases expected to fail due to open bugzillas
- bugzillas covered: 14323, 14600, 14541, 14437, 14540, 14541



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170564 91177308-0d34-0410-b5e6-96231b3b80d8
Skip libc++ data formatter tests on Linux because there is no standard location for the makefile to find libc++.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170575 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes the SymbolFileSymtab support 
for reporting class types from Objective-C runtime
class symbols.  Instead, LLDB now queries the 
Objective-C runtime for class types.

We have also added a (minimal) Objective-C runtime
type vendor for Objective-C runtime version 1, to 
prevent regressions when calling class methods in
the V1 runtime.

Other components of this fix include:

- We search the Objective-C runtime in a few more
  places.

- We enable enumeration of all members of
  Objective-C classes, which Clang does in certain
  circumstances.

- SBTarget::FindFirstType and SBTarget::FindTypes
  now query the Objective-C runtime as needed.

- I fixed several test cases.

<rdar://problem/12885034>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170601 91177308-0d34-0410-b5e6-96231b3b80d8
Disable confirmation prompt in TestProcessLaunch (to avoid hang on Linux once bug is fixed)



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170603 91177308-0d34-0410-b5e6-96231b3b80d8
Mark register tests as expectedFailureLinux because of bugzilla reports 14600 and 14661.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170605 91177308-0d34-0410-b5e6-96231b3b80d8
<rdar://problem/12446222>

Implement the ability for Python commands to be interrupted by pressing CTRL+C
Also add a new Mutex subclass that attempts to be helpful for debugging by logging actions performed on it

FYI of all interested - there is a separate deadlocking issue related to how LLDB dispatches CTRL+C that might cause LLDB to deadlock upon pressing CTRL+C while in a Python command.
This is not a regression, and was just previously masked by us not even trying to bail out of Python commands, so that it would not be clear from a user perspective whether we were
deadlocked or stuck in an inconsistent state within the Python interpreter.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170612 91177308-0d34-0410-b5e6-96231b3b80d8
Setting TestInferiorChanged.py to expectedFailureLinux because of bugzilla 14662.

Note that the test actually fails before reaching the assertion described in that bug, but the failure is a trivial matter of adding OS-conditional expected stop reason strings (as noted by new comments in this patch).  However, with the stop reason strings changed, the test fails for the more substantial reason noted in bugzilla 14662.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170619 91177308-0d34-0410-b5e6-96231b3b80d8