Re: [rfc] Delay deletion of step-resume breakpoints

[Daniel Jacobowitz <drow@false.org>]

On Mon, Aug 13, 2007 at 11:13:32PM +0200, Mark Kettenis wrote:
> The change you made to the comment:
> 
> >    /* NOTE: this will take care of any left-over step_resume breakpoints,
> > -     but not any user-specified thread-specific breakpoints. */
> > +     but not any user-specified thread-specific breakpoints.  We can not
> > +     delete the breakpoint straight-off, because the inferior might not
> > +     be stopped at the moment.  */
> 
> Makes me suspect this is just a workaround for another bug, the bug
> being that the inferior isn't properly stopped when this code gets
> called.

That's supposed to be not a bug - I think.  We've detected a thread
exit while waiting for an interesting event; since thread exit isn't
generally considered "interesting" in this context, we keep waiting.
If your OS stops all threads for you at every event (HP/UX ttrace
does, I think) then that doesn't matter.  If your OS doesn't (Solaris
PR_ASYNC, GNU/Linux) then you might detect that thread exit while the
other threads are not yet stopped.

Or something else might have already resumed the other threads; I am
working on remote protocol notifications for stopped threads, and I
don't want to leave the entire target stopped while waiting for GDB to
ack.  Jim's come up with a sensible design I can reuse for this,
we'll post it soon I hope.

So we can delay deleting the thread until the next time we need to
stop all threads, but that's awkward - see record_dead_thread in
linux-nat.c.  Or we can let delete_thread handle the problem.

So should delete_thread be callable when the target is running or
should any target that might call it when the target is not running
maintain its own list the way the Linux native layer does?  We don't
have any formal specifications on what can be called when :-(

-- 
Daniel Jacobowitz
CodeSourcery