Re: Keeping breakpoints inserted

[Jim Blandy <jimb@codesourcery.com>]

Michael Snyder <msnyder at specifix.com> writes:
> There will be some as-it-were non-deterministic behavior, 
> it seems to me.  If threads are running while we are inserting
> breakpoints, then there will (at some point) be breakpoint
> events while we are inserting breakpoints, and the order of
> these events (and of running-threads stopping) will depend
> on the order in which we insert them, as well as on what 
> the running threads happen to be doing at the time.
>
> I should think that this would be more intrusive (in the 
> sense of changing the behavior of the target program) than
> we already are.
>
> We could see a deadlock develop during the time it takes us
> to insert all the breakpoints.

Since breakpoints only make the threads that hit them execute "very
slowly", I don't see how they could introduce a deadlock in code that
didn't already have the potential for deadlock in the absence of a
debugger.

It's true that the breakpoints won't all appear in the address space
simultaneously.  It might be useful to be able to insert breakpoints
disabled, and then enable them as a group.  Even in all-stop mode, GDB
isn't able to stop all threads simulataneously; it has to obtain the
list of threads and send each one a signal.  So it seems to me that
some degree of 'play' in breakpoint insertion isn't so different from
what we have now.

Inserting breakpoints into code that's currently being executed
inevitably entails race conditions.  But I expect one would only do
such a thing in circumstances where it's meaningful and controllable.

For example, you might know that you'll reach the breakpoint only in
response to a certain input, which you'll send to the program after
you've set the breakpoint.

Or, it might not matter which particular execution of the code you
catch first, you just want to interrupt it.

Non-stop debugging is more invasive than all-stop debugging, if you
assess invasiveness by looking at how the threads progress relative to
each other.  Non-stop debugging can make one thread run 'extremely
slowly' while other threads progress at a normal rate.  All-stop
debugging stops all threads roughly equally (but even then not
perfectly so).

However, non-stop debugging can be less invasive than all-stop
debugging, if you assess invasiveness by looking at how responsive the
system remains to outside events.  With non-stop debugging, you can
debug one particular thread out of the entire system while the others
continue to work normally.

Deciding which mode to use depends on the developer's knowledge of the
system they're debugging.