> 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?
We should probably invent a "stopped by user interrupt" stop reply that we can get from debugserver. Right now debugserver just reports the results of whatever mechanism it uses to interrupt the target, which is generally a SIGSTOP. Signals get delivered to one thread, so the stop reply will say that thread stopped with a SIGSTOP. But I don't quite understand what you mean by "at a low level we'll end up stopping all 5 threads". When you hit a breakpoint on one thread, do you also have to stop the other threads? And if so, do you report that as the stop reason for those threads? That would be wrong, since the stopping of those threads is an implementation detail, and showing that those threads stopped for some reason that doesn't relate to their current state would be confusing. If you don't report the internal stopping of threads for a breakpoint hit, why do you have to do that for interrupt? > > 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. I don't know why this would take multiple restarts. If you hit two breakpoints on two different threads simultaneously, then internally you'll have to step over each of them to get the process going again. But that's just a detail of how software breakpoints work. If they were hardware breakpoints, you could just restart. What's going on that you have to do multiple restarts. > > 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? We don't currently do "keep alive" debugging, so I'm not quite sure why the thread would not be stopped. How is that happening. Anyway, I don't think there's a stop reason for "not actually stopped". E seems a crude way to indicate this, however, so when we get around to keep alive debugging we should invent a reply that indicates not stopped as distinct from "got an error reading the thread status..." Jim > > 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 _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
