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 | tfi...@google.com | 650-943-3180
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
