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.
You guys gave me enough info to work through it from here. Thanks! On Thu, Sep 11, 2014 at 9:50 AM, Greg Clayton <gclay...@apple.com> wrote: > > > On Sep 11, 2014, at 8:41 AM, Todd Fiala <tfi...@google.com> wrote: > > > > 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? > > 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. > > > > > 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. > > You should tell the truth and just tell us which thread got the signal if > you can determine this. > > > This seems to translate to lldb thinking it needs multiple restarts to > get it going again. > > 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. > > > > > 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? > > 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. > > > > > 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 > > We aren't marking anything, we are just telling the truth by converting > the actual system exception information into a stop reply packet. > > > whereas Linux/llgs is marking all threads with the SIGSTOP stop reason. > > 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. > > > 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. > > > > 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. > > Greg > -- 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
