This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Stand resume() on its head
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?
Per Michael's comment when the user explicitly suspends a thread.
Also, a thread-hop would mean suspending some threads, single-stepping one.
- 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.
For the moment none :-) However, yes, down the track that will become
possible.
The other side of this would be having each thread's state updated as it
arrived (instead of reaping all the status and then going back to wfi).
- 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.
The remote Hc discussion identified two cases:
- thread-hop
- single-step thread
In the case of shlib, all the other threads would already being in the
running state (so would need no action). Just one stopped thread would
need a stepi.
- 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.
I think we'll need that anyway. But hopefully independentish - resume
can be implemented independant of the wait side.
-- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Andrew