[lldb-dev] thread state question on Ctrl-C

[Todd Fiala]

Hey guys,

When we hit Ctrl-C in lldb while debugging a multithreaded inferior with 5
threads, at a low level we'll end up stopping all 5 threads.  It looks like
our expectation is that one of the 5 threads gets marked with a stop
reason, while the other 4 threads in this case would simply report they are
stopped for no reason (gdb-remote T00 stop reason).  Is that correct?

Right now in llgs I believe I'm doing this in a non-compliant way.  I am
marking all threads as stopped with the stop reason for an interrupt.  This
seems to translate to lldb thinking it needs multiple restarts to get it
going again.

Related - if I do a qThreadStopInfo gdb-remote command and the thread is
*not* stopped, that is an error that gets an E response.  But if it is
stopped but not for any user-visible reason, that is a T00 response.  Is
that correct?

The difference between MacOSX/debugserver and Linux/llgs is visible in the
test/tools/lldb-gdbserver/TestGdbRemote_qThreadStopInfo.py test if you log
the stop signals returned by the qThreadStopInfo that loops over all
threads.  MacOSX is only marking one with a stop reason of non-zero,
whereas Linux/llgs is marking all threads with the SIGSTOP stop reason.
 That particular test isn't checking that aspect, but obviously I want to
add a test that verifies we're handling the stop reason marking correctly
on the llgs side.

Thanks!
-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140911/c2b9c86e/attachment.html>