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

[Todd Fiala]

Great, thanks Greg!


On Mon, Jun 30, 2014 at 11:32 AM, Greg Clayton <gclayton at apple.com> wrote:

> 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
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>



-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140630/d48a9f06/attachment.html>