This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Keeping breakpoints inserted
- From: Michael Snyder <msnyder at specifix dot com>
- To: Jim Blandy <jimb at codesourcery dot com>
- Cc: Thiago Jung Bauermann <bauerman at br dot ibm dot com>, Vladimir Prus <vladimir at codesourcery dot com>, gdb at sources dot redhat dot com
- Date: Fri, 30 Nov 2007 17:30:22 -0800
- Subject: Re: Keeping breakpoints inserted
- References: <200711292224.23659.vladimir@codesourcery.com> <1196456622.6746.169.camel@localhost.localdomain> <1196458063.2501.153.camel@localhost.localdomain> <m363zjuvi2.fsf@codesourcery.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.