Re: Stand resume() on its head

Daniel Jacobowitz
2002-11-05T20:59:05Z

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?

- User interface for this? 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.

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

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

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer