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

[Todd Fiala]

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