[lldb-dev] thread state question on Ctrl-C
tfiala at google.com
Thu Sep 11 08:41:38 PDT 2014
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
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
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.
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev