<div dir="ltr">I'll need to go through it in detail.  I suspect I'm actually sending a SIGSTOP to each thread  on Ctrl-C which I think is the root of the issue - I only need to do that to one.<div><br></div><div>You guys gave me enough info to work through it from here.  Thanks!</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 11, 2014 at 9:50 AM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Sep 11, 2014, at 8:41 AM, Todd Fiala <<a href="mailto:tfiala@google.com">tfiala@google.com</a>> wrote:<br>
><br>
</span><span class="">> Hey guys,<br>
><br>
> 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?<br>
<br>
</span>You should show what actually happens in the system. If all 5 threads actually stop due to a signal, show that. So try to show the truth as much as you can. It would be great if we actually were able to stop the program some other way that doesn't involve a signal being thrown, but none of us have that as far as I know. It would be great to get all threads stopped with no stop reason, but we currently should show the truth about how the program stopped (SIGSTOP) in case when you resume the SIGSTOP got delivered to your program you would want to be able to understand why it did such a thing.<br>
<span class=""><br>
><br>
> 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.<br>
<br>
</span>You should tell the truth and just tell us which thread got the signal if you can determine this.<br>
<span class=""><br>
> This seems to translate to lldb thinking it needs multiple restarts to get it going again.<br>
<br>
</span>Signals shouldn't require multiple starts. They don't on MacOSX. We determine, using the current UnixSignals from the process, if we suppress them or not and just resume the program.<br>
<span class=""><br>
><br>
> 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?<br>
<br>
</span>qThreadStopInfo should always return a valid response for any real thread. It can't be sent while the process is running because when the process is running you are in the middle of a "c" or "vCont..." packet and waiting for the stop reply. T00 should be returned for any thread was simply suspended because we wanted to stop the process, yes that is correct.<br>
<span class=""><br>
><br>
> 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<br>
<br>
</span>We aren't marking anything, we are just telling the truth by converting the actual system exception information into a stop reply packet.<br>
<span class=""><br>
> whereas Linux/llgs is marking all threads with the SIGSTOP stop reason.<br>
<br>
</span>So the question is: when you interrupt your target, how are you doing it? Sending a SIGSTOP? Does any thread actually have a stop reason? If you have no threads with no real stop reasons, you will need to mark at least one thread with a stop reason of "reason:interrupted;" (and add corresponding code to ProcessGDBRemote::SetThreadStopInfo(...) to handle the new "interrupted" reason.<br>
<span class=""><br>
>  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.<br>
><br>
<br>
</span>So tell the truth as much as possible, and if you are interrupting and have to make up a new stop reason, use the "interrupted" on a single thread (the first one probably) if no threads actually have a stop reason to report after halting your process.<br>
<span class="HOEnZb"><font color="#888888"><br>
Greg<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</div>