Re: RFC: Two small remote protocol extensions

[Andrew Cagney <ac131313 at ges dot redhat dot com>]

> Sure.  I suppose we should clean up the interface to resume, to prevent
> all this confusion re-arising... which means figuring out our possible
> behaviors, and whether they are even implementable on particular
> targets.
The spanner in the works here is simulators.  They can't implement 
schedule-locking because their scheduler is hardwired.  The best they 
can manage is step off current instruction.

A simple version of this (PPC) (from memory) always implements 
step->schedule.  If you step I the procesor.  It complets one 
instruction on the current CPU and then schedules the next CPU for the 
next instruction.

> On Linux the options for any given LWP (at the moment, that means for
> any given thread) are step, run, stop.  All combinations are available. 
> I think the _useful_ ones are:
>
>   step one, stop others
>   step one, continue others
>   continue one, stop others
>   continue one, continue others
>
> And, of course:
>   stop one, stop others
> :)
What is the absolute minimum needed?

- step off breakpoint / thread-hop
= using a sched lock single-step
= using software single-step breakpoints and a sched lock continue 
(Note: this is where the existing interface really falls down -- step=0 
so remote.c won't know to schedule-lock)

- continue

I think, after that, everything is an efficiency gain.  Looking at the list:

>   step one, stop others

Hardware single-step off of breakpoint.
TPID, STEP, !OTH
HcTID, s

>   step one, continue others

Hardware single-step.
TPID, STEP, OTH
H???, s

>   continue one, stop others

Schedule lock.
Software single-step off breakpoint.
TPID, !STEP, !OTH (wiered)
HcTID, c

>   continue one, continue others

Software single-step.
General resume.
TPID, !STEP, OTH
Hc0, c

> Something like:
>   resume (ptid, step, run_others, target_signal)
> maybe?  Does anyone think step_all is useful (I don't)?

It is what a simulator might implement.

So looking at the remote protocol.  There in't a way of specifying TPID, 
STEP, OTH (your bug).

Andrew




> PS:
> Some day letting the user be more precise (run these two threads) would
> be nice.  I envision a day in the distant future:
>  -> Continue thread 1
>  -> Continue thread 2
>  -> Wait for inferior status
>  <- All threads stopped, thread 1, SIGSEGV
> or
>  -> Continue all threads
>  -> Wait for inferior status [maybe implicit in the all-threads
> 				request]
>  <- Thread 1 stopped, shared lib breakpoint, all other threads running
Try ``target remote-async''.

> But let's not try to design to that quite yet :)
:-)