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

[Todd Fiala]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140628/4333b927/attachment.html>