Re: Stand resume() on its head

[Andrew Cagney <ac131313@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?

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