After solving the issue in llvm.org/pr17226 these two tests still fail,
now for other reasons.

llvm-svn: 194729

After solving llvm.org/pr17226 these two tests now fail for the same reason
they do on Linux.

llvm-svn: 194726

llvm-svn: 194631

Add a log message to the console that will display the error code when we fail to reply to a mach message.

llvm-svn: 194623

Added two new GDB server packets to debugserver: "QSaveRegisterState" and "QRestoreRegiterState".

"QSaveRegisterState" makes the remote GDB server save all register values and it returns a save identifier as an unsigned integer. This packet can be used prior to running expressions to save all registers.

All registers can them we later restored with "QRestoreRegiterState:SAVEID" what SAVEID is the integer identifier that was returned from the call to QSaveRegisterState.

Cleaned up redundant code in lldb_private::Thread, lldb_private::ThreadPlanCallFunction.
Moved the lldb_private::Thread::RegisterCheckpoint into its own header file and it is now in the lldb_private namespace. Trimmed down the RegisterCheckpoint class to omit stuff that wasn't used (the stack ID).

Added a few new virtual methods to lldb_private::RegisterContext that allow subclasses to efficiently save/restore register states and changed the RegisterContextGDBRemote to take advantage of these new calls.

llvm-svn: 194621

Remove the --do-read option, and always provide a small dump of memory at each match spot
Add a --dump-offset (-o) option, to specify a byte offset from which to start dumping relative to the matching address

The real solution is to actually provide the format options found on "memory read" and use those as the key to actually printing memory upon each find
That, however, requires a little refactoring work, so put this in for now until I get a chance to do the required shuffling around of moving parts

llvm-svn: 194600

llvm-svn: 194587

llvm-svn: 194546

Implement a "memory find" command for LLDB

This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in
mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r

llvm-svn: 194544

SBThread::GetExtendedBacktraceThread to make it more clear what is
being returned.

llvm-svn: 194531

In order to help track down llvm.org/pr17226.

llvm-svn: 194487

This mirrors lld r194481

llvm-svn: 194483

llvm-svn: 194455

the HistoryThread dtor.

llvm-svn: 194436

llvm-svn: 194413

llvm-svn: 194397

These were previously missing in g_register_infos_x86_64 and so arg
lookup failed on FreeBSD and Linux after r194035.

llvm-svn: 194392

llvm-svn: 194371

something; add a new ExtendedThreadList to Process where they can be retained
for the duration of a public stop.
<rdar://problem/15314068> 

llvm-svn: 194367

something; add a new ExtendedThreadList to Process where they can be retained
for the duration of a public stop.
<rdar://problem/15314068> 

llvm-svn: 194366

llvm-svn: 194363

- removed all gaps from the g/G packets
- optimized registers for x86_64 to not send/receive xmm0-xmm15 as well as ymm0-ymm15, now we only send ymm0-15 and xmm0-15 are now pseudo regs
- Fixed x86_64 floating point register gaps
- Fixed x86_64 so that xmm8-xmm15 don't overlap with ymm0-ymm3. This could lead to bad values showing in the debugger and was due to bad register info structure contents
- Fixed i386 so we only send ymm0-ymm7 and xmm0-xmm7 are now pseudo regs.
- Fixed ARM register definitions to not have any gaps
- Fixed it so value registers and invalidation registers are specified using register names which avoid games we had to play with register numbering in the ARM plugin.

llvm-svn: 194302

There were 6 on darwin. All of these were related to the recent changes for exec.

llvm-svn: 194298

llvm-svn: 194295

Still working out some of the details of these classes but 
I wanted to get the overall structure checked in.
<rdar://problem/15314068> 

llvm-svn: 194245

llvm::ArrayRef of arguments rather than taking
a fixed number of possibly-NULL pointers to
arguments.

Also changed ClangFunction::GetThreadPlanToCallFunction
to take the address of the argument struct by value
instead of by reference, since it doesn't actually
modify the value passed into it.

llvm-svn: 194232

It completes the job of using EvaluateExpressionOptions consistently throughout
the inferior function calling mechanism in lldb begun in Greg's patch r194009. 

It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which
were there for convenience.  Using the EvaluateExpressionOptions removes the need for them.

Using that it gets the --debug option from Greg's patch to work cleanly.

It also adds another EvaluateExpressionOption to not trap exceptions when running expressions.  You shouldn't
use this option unless you KNOW your expression can't throw beyond itself.  This is:

<rdar://problem/15374885>

At present this is only available through the SB API's or python.

It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether
they were set by somebody else already.

llvm-svn: 194182

llvm-svn: 194163

iterators for LLDB's container data structures.
Iterable abstracts over the backing data structure,
ignoring keys for maps for example.  It also provides
locking as a service so that the code

for (ThreadSP thread_sp : process->Threads())
{
  // ... use thread_sp
}

takes the appropriate locks once, without having to
do anything else.

The salient advantages of this system are:

- Much simpler and idiomatic loop code
- Lock once instead of each time an element is fetched
- Less boilerplate to produce the iterators

The intent is that Iterable will replace Get...AtIndex
in most places, and that ForEach(), which solves the
same problem in a less-idiomatic way, be phased out in
favor of this approach.

I've added Iterables to ThreadList, TypeList, and
Process (which is really just forwarding to ThreadList).

llvm-svn: 194159

bit from the method names.
<rdar://problem/15314369> 

llvm-svn: 194122

Improve lldb_private::Address to detect when section was deleted and not return bogus values for GetLoadAddress() and GetFileAddress().

llvm-svn: 194120

SystemRuntime and SBThread classes.
<rdar://problem/15314369> 

llvm-svn: 194111

Fixed the test case for "test/functionalities/exec/TestExec.py" on Darwin.

The issue was breakpoints were persisting and causing problems. When we exec, we need to clear out the process and target and start fresh with nothing and let the breakpoints populate themselves again. This patch correctly clears out the breakpoints and also flushes the process so that the objects (process/thread/frame) give out valid information.

llvm-svn: 194106

<rdar://problem/15390829>

llvm-svn: 194087

GetThreadOriginExtendedBacktraceTypeAtIndex methods to
SBProcess.

Add documentation for the GetQueueName and GetQueueID methods
to SBThread.
<rdar://problem/15314369> 

llvm-svn: 194063

SystemRuntime class.
<rdar://problem/15314369> 

llvm-svn: 194045

class, not any actual plugin implementation yet.
<rdar://problem/15314068> 

llvm-svn: 194044

Instead of looking up registers by name, we use the generic ID when we can.

Also added code that creates an extra frame when running expressions by pushing the current PC and FP and then hooking up the FP backchain. This code is "#if 0" out for now until we can pair it with unwinder fixes.

llvm-svn: 194035

the stack pointer.

llvm-svn: 194029

where it was using the wrong register numbering scheme
to express where the rbp could be retrieved from.

llvm-svn: 194023