Learned that MacOSX only accepts signal delivery on a thread that is
already signal handling. Reworked the test exe to cause a SIGSEGV
and recover if either nothing intercepts the SIGSEGV handler, or
if a SIGUSR1 is inserted. The test uses the latter part to test
signal delivery on continue using the SIGUSR1.
I still don't have this working on MacOSX. I'm seeing the
signal get delivered to a different thread than the one I'm
specifying with $Hc{thread-id} + $C{signo}, or with
$vCont;C{signo}:{thread-id};c. I'll come back to this
after getting it working on the llgs branch on Linux x86_64.
llvm-svn: 209912
Added new SocketPacketPump class to decouple gdb remote packet
reading from packet expectations code. This allowed for cleaner
implementation of the separate $O output streams (non-deterministic
packaging of inferior stdout/stderr) from all the rest of the packets.
Added a packet expectation matcher that can match expected accumulated
output with a timeout. Use a dictionary with "type":"output_match".
See lldbgdbserverutils.MatchRemoteOutputEntry for details.
Added a gdb remote test to verify that $Hc (continue thread selection)
plus signal delivery ($C{signo}) works. Having trouble getting this
to pass with debugserver on MacOSX 10.9. Tried different variants,
including $vCont;C{signo}:{thread-id};c. In some cases, I get the
test exe's signal handler to run ($vCont variant first time), in others I don't
($vCont second and further times). $C{signo} doesn't hit the signal
handler code at all in the test exe but delivers a stop. Further
$Hc and $C{signo} deliver the stop marking the wrong thread. For now I'm
marking the test as XFAIL on dsym/debugserver. Will revisit this on
lldb-dev.
Updated the text exe for these tests to support thread:print-ids (each
thread announces its thread id) and provide a SIGUSR1 thread handler
that prints out the thread id on which it was signaled.
llvm-svn: 209845
Todd Fiala