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: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 5 Nov 2002 15:59:57 -0500
- Subject: Re: Stand resume() on its head
- References: <3DC829E3.4090603@redhat.com>
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