Re: Stand resume() on its head

Michael Snyder
2002-11-05T22:15:26Z

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