llgs: add logging to Native*Protocol breakpoints around byte values replaced and restored.

Useful for verifying what bytes a software breakpoint clobbers/restores.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219318 91177308-0d34-0410-b5e6-96231b3b80d8
Skip asan test on FreeBSD

The build fails due to missing asan runtime in the FreeBSD base system.
Instead of marking it expected fail, just skip until we have the runtime
available.

llvm.org/pr21136


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219328 91177308-0d34-0410-b5e6-96231b3b80d8
Add decorator for FreeBSD failure

llvm.org/pr21211


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219329 91177308-0d34-0410-b5e6-96231b3b80d8
Extend synthetic children to produce synthetic values (as in, those that GetValueAsUnsigned(), GetValueAsCString() would return)

The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function.
If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value

The rationale for doing things this way is twofold:

- there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial
- we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix
On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature

Comes with a test case



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219330 91177308-0d34-0410-b5e6-96231b3b80d8
Add a (Python only) lldb.SBSyntheticValueProvider class to our API surface
On a suggestion from Jim Ingham, this class allows you to very easily define synthetic child providers that return a synthetic value (in the sense of r219330), but no children

Also, document this new feature in our www docs



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219337 91177308-0d34-0410-b5e6-96231b3b80d8
Fix deadlock in Python one-line execution.

Python one-line execution was using ConnectionFileDescriptor to do
a non-blocking read against a pipe.  This won't work on Windows,
as CFD is implemented using select(), and select() only works with
sockets on Windows.

The solution is to use ConnectionGenericFile on Windows, which uses
the native API to do overlapped I/O on the pipe.  This in turn
requires re-implementing Host::Pipe on Windows using native OS
handles instead of the more portable _pipe CRT api.

Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5679

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219339 91177308-0d34-0410-b5e6-96231b3b80d8
Fix compile error on posix.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219340 91177308-0d34-0410-b5e6-96231b3b80d8
Add a SyntheticValueProviderFrontEnd that serves internally the same purpose as lldb.SBSyntheticValueProvider serves on the API layer

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219352 91177308-0d34-0410-b5e6-96231b3b80d8
POSIX dynamic loader: add more logging around launch/attach, fix breakpoint handling on entry callback.

This change adds some logging around dynamic loader handling.
It also fixes an issue where the dynamic loader entry breakpoint can end
up being re-inserted, showing the wrong (i.e. software breakpoint) instruction
at the stop location when a backtrace is displayed at program startup.

I discussed with Jim Ingham a few weeks back.  Essentially the
one-hit breakpoints need to make it back to public state handling before
the software breakpoint gets cleared.  The flow I was hitting was that
the breakpoint would get set, it would get hit, it would get cleared to
step over, then it would get reapplied, when we never wanted it reapplied.
Stops at the beginning of execution would then show backtraces with
software breakpoint instructions in it, erroneously.  This change fixes it.
There might be a more elegant way to do this, or a flow change somewhere else
to avoid, but it does fix an issue I experienced in startup breakpoint handling.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219371 91177308-0d34-0410-b5e6-96231b3b80d8
Fix MacOSX Xcode build for Pipe changes.

Also cleans up the lldb Xcode project's Source > Host > posix directory
to use group-relative file naming.  Also alphabetizes file entries.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219373 91177308-0d34-0410-b5e6-96231b3b80d8
Added a bit of logging around GDBRemoteCommunicationClient::SendGDBStoppointTypePacket.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219374 91177308-0d34-0410-b5e6-96231b3b80d8
logging: added more logging to the Target/Platform launch & attach sequence.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@219377 91177308-0d34-0410-b5e6-96231b3b80d8
Merge upstream llvm.org r219377 into dev-llgs-local-launch