llvm-svn: 176059

Fixed issues with the SBModule "sections" property, and with the SBBlock "ranges" attributes.

llvm-svn: 176051

llvm-svn: 176049

- was causing buildbot failures due to unexpected pass

llvm-svn: 176048

llvm-svn: 176041

Make sure to not look in self.images when we have a symbolicator with a live process.

llvm-svn: 176040

Add a log line when debugserver exits, and clean up some of the other standard logs output to make it more useful.

llvm-svn: 176039

Need available CPU on target device to support CPU reporting.

llvm-svn: 176008

StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.

llvm-svn: 175953

in the gdb-remote Process plugin files.

llvm-svn: 175947

llvm-svn: 175946

Fixing issues in previous checkin - still figuring out how to make expectedFailureClang take the bugnumber

llvm-svn: 175945

llvm-svn: 175944

The decorators @expectedFailure (plain and special-case like i386, clang, ...) are modified to optionally take a bugnumber argument
If such an argument is specified, the failure report (or unexpected success report) will include the information passed in as part of the message
This is mostly useful for associating failures to issue IDs in issue management systems (e.g. the LLVM bugzilla)

llvm-svn: 175942

Need host_statistics on profile data to get host's user/system/idle clicks

llvm-svn: 175928

<rdar://problem/13270229>

llvm-svn: 175927

<rdar://problem/13270100>

llvm-svn: 175926

Fixed an issue where if we got a 'A' async packet back from debugserver, we would resend the last continue command. We now correctly identify the packet as async (just like the 'O' stdout async packet) and we don't resend the continue command.

llvm-svn: 175924

The thread plans run before the event is broadcast, so they should be calling ShouldStopSynchronous on any Stop Info's
they want to check.  The full ShouldStop should only be called on the public side of the event system.

llvm-svn: 175922

llvm-svn: 175917

llvm-svn: 175915

llvm-svn: 175873

own port namepsace) as the thread identifier to using the system-wide
globally unique thread id as the thread identifier number.

MachThread.cpp keeps both the unique id and the mach port number
for each thread.  All layers outside MachThread class use the unique
id with three exceptions: (1) Mach exceptions come in with the port
number (thread_port) which needs to be translated, (2) any calls to
low-level thread_get_state/thread_set_state/thread_suspend etc need
to use the mach port number, (3) MachThreadList::UpdateThreadList 
which creates the MachThread objects gets the unique id and passes
it to the MachThread ctor as an argument.

In general, any time nub_thread_t is used, it is now referring to a
unique thread id.  Any time a thread_t is used, it is now referring
to a mach port number.  There was some interchangability of these 
types previously.  nub_thread_t has also been changed to a 64-bit
type which necessitated some printf specification string changes.

I haven't been able to test these changes extensively yet but want
to checkpoint the work.  The scenarios I've been testing are all
working correctly so while there may be some corner cases I haven't
hit yet, I think it is substantially correct.

<rdar://problem/12931414> 

llvm-svn: 175870

Using __package__ and __name__ seems redundant - __name__ should always contain the fully qualified module name

llvm-svn: 175856

llvm-svn: 175845

- replace "catch-all" except clause with one that specifically catches what pexpect throws
- handle case where child is already terminated (or is terminating) by the time tear-down is run

llvm-svn: 175844

llvm-svn: 175842

This was preventing us from providing a summary for the result of std::string.c_str() with libc++

llvm-svn: 175841

llvm-svn: 175832

The notion of Crossref command has long been forgotten, and there is nothing using CommandObjectCrossref in the current LLDB codebase
However, this was causing a conflict with process plugins and command aliases ending up in an infinite loop under situations such as:
(lldb) command alias monitor process plugin packet monitor
(lldb) process att -n Calendar
Process 28709 stopped
Executable module set to "/Applications/Calendar.app/Contents/MacOS/Calendar".
Architecture set to: x86_64-apple-macosx.
(lldb) command alias monitor process plugin packet monitor

This fixes the loop (and consequent crash) by disposing of Crossref commands and related code

llvm-svn: 175831

llvm-svn: 175829

On x86-64 platforms, the small code model assumes that code will be loaded below the 2GB boundary.  With the static relocation model, the fact that the expression code is initially loaded (in the LLDB debugger address space) above that boundary causes problems.  Switching to the JITDefault code model causes the large code model to be used for 64-bit targets and small code model of 32-bit targets.

llvm-svn: 175828

llvm-svn: 175822

llvm-svn: 175816

llvm-svn: 175811

llvm-svn: 175810

functions start at the line with the "{" character, whereas clang uses the first line
with source code. As such, this test case will only work with clang.

llvm-svn: 175808

<rdar://problem/13254824>

llvm-svn: 175806

llvm-svn: 175801

llvm-svn: 175798