[lldb-dev] correct remote stub behavior w/r/t some all-stop scenarios

[Greg Clayton]

I think you have it right Todd: new threads shouldn't generate a user visible stop and the process should resume. It takes one or more threads to stop with a valid reason (bp, wp, signal, exception) before all threads should be stopped.

Greg



> On Jun 28, 2014, at 9:12 PM, Todd Fiala <todd.fiala at gmail.com> wrote:
> 
> > I noticed on the local debugging side that the following events result in all threads stopping (at least as a private stop, and at least on local Linux debugging):
> So - slightly more data.  Specifically related to the new-thread secenario, I have *not* been having llgs on linux x86_64 issue a stop for a new thread when it came online, even though I know about and track the new thread. This seems to be matching the debugserver behavior.  I'm going to write some gdb-remote level tests around that specifically.  When I tried having the new thread stop instead of having it immediately resume, I started seeing a number of gdb-remote tests fail around extra stop notifications (that I don't get on debugserver).  That makes me wonder about why the local Linux ProcessMonitor/ProcessPOSIX/ProcessLinux combo seems to do a stop of the new thread and a stop-all when a new thread comes online.
> 
> For now I'm going to leave the new thread scenario as is - having it not generate a thread stop for itself (and certainly not for all threads - I'm still thinking the all-stop scenarios are intended to be handled by the client and not the stub/NativeProcessProtocol).
> 
> Greg, I'm sure you'll set me straight when you see this ;-)
> 
> -Todd
> 
> 
> On Sat, Jun 28, 2014 at 3:21 PM, Todd Fiala <todd.fiala at gmail.com> wrote:
> Hey all,
> 
> I noticed on the local debugging side that the following events result in all threads stopping (at least as a private stop, and at least on local Linux debugging):
> 	• new thread creation
> 	• breakpoint/trace hit
> 	• watchpoint hit
> 	• crash
> Regarding a remote stub, (ab) should I assume that the client will request all threads stop when those events occur and are reported by a stop notification, such that the stub can ignore those details, or (b)  should the stub perform an all-stop in all of those cases before reporting the triggering event(s)?
> 
> e.g.
> 1. New thread is detected on stub.
> 
> At this point - do I just keep the thread stopped and report a stop result for the thread, or do I make sure all threads are stopped, then report the stop?
> 
> 2. Breakpoint hit.
> 
> At this point - do I just report the breakpoint being hit with a stop notification, or do I stop all threads first and then report the breakpoint being hit on the thread?
> 
> Similarly for watchpoints, etc.
> 
> Thanks!  I'm hopeful the answer is "the client handles the details of all other thread behavior, just report what you see on the stub."
> 
> I'm walking through all the llgs signal handling code and trying to make sure it's all doing the proper actions, but comparison to the local debugging case is not always helpful since local debugging is essentially the same as client+stub in the remote case, and the line of what is a client responsibility vs. a stub responsibility is less clear.
> 
> Much appreciated!
> -Todd
> 
> 
> 
> 
> -- 
> -Todd
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev