This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Stand resume() on its head
- From: Michael Snyder <msnyder at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>, gdb-patches at sources dot redhat dot com
- Date: Tue, 05 Nov 2002 14:15:15 -0800
- Subject: Re: Stand resume() on its head
- Organization: Red Hat, Inc.
- References: <3DC829E3.4090603@redhat.com> <20021105205957.GA15963@nevyn.them.org>
Daniel Jacobowitz wrote:
>
> On Tue, Nov 05, 2002 at 03:28:19PM -0500, Andrew Cagney wrote:
> > Hello,
> >
> > There have now been several discussion threads that lead to the
> > conclusion that
> >
> > target->resume (ptid_t, int, enum target_signal)
> >
> > needs changing. At present the suggestion is to add a parameter to
> > indicate schedule locking and similar operations.
> >
> > I'd like to propose a different approach. Instead of passing to
> > resume() what to do, have resume() iterate over all the threads asking
> > each what it should do - suspend, step, run, signal, ...
> >
> > I think, in the end, GDB will need to do something like this any way
> > (how else is GDB going to handle suspended threads?) so might as well
> > start earlier rather than later :-)
>
> I like it, roughly speaking. I've got a couple of other thoughts and
> some questions:
> - What do you mean by suspended threads?
Just what you think -- give the user the ability to say
"this thread should not resume when the others do."
> - User interface for this?
Important, and yet to be worked out. Wanna start the discussion?
> We could use this opportunity to fix
> and clarify passing signals. A command to show pending signals
> per-thread for the next resume; a command to set them.
Hmmmm!
> - Why would we want to step a particular thread in a resume? If we
> want to single-step a particular thread then it seems to me that we
> want to do it independently of resuming other threads.
Currently that's true. I can't think of a circumstance where it
wouldn't be true, but I haven't thought real hard about it.
> - Is there a useful way to combine this with a mechanism to report
> more than one event from a wait? More than one thread stopping with a
> signal, for instance. That'll also need interface changes, but we need
> the interface changes anyway: see the failing test for hitting a
> watchpoint and a breakpoint at the same time, in annota2.exp.
In a single-processor system, I don't think that can happen.
It's bogus that Linux-gdb lets it appear to happen (at least internally).
But yeah, it can sure happen in a multi-processor environment.
Have any thoughts to share about that interface?
Michael