Re: Keeping breakpoints inserted

[Michael Snyder <msnyder at specifix dot com>]

On Fri, 2007-11-30 at 16:08 -0800, Jim Blandy wrote:
> 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.

Well, just 'cause you've changed the timing.  Thread A holds
a resource that thread B needs; thread A hits a breakpoint 
but thread B gets to keep running (for a while) because you
haven't finished inserting breakpoints.

> 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.

No, it's just more of what is already an intrusive thing.
It's worse in degree, not in kind.