[lldb-dev] correct remote stub behavior w/r/t some all-stop scenarios
todd.fiala at gmail.com
Sat Jun 28 15:21:48 PDT 2014
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
- new thread creation
- breakpoint/trace hit
- watchpoint hit
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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev