Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Aug 28, 2002 at 12:06:38AM -0400, Andrew Cagney wrote:
> 
> >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.

OK, makes sense.

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

OK, I suppose that makes sense.  It's pretty much where I was to begin
with: if Hc is non-zero, lock to that thread; if Hc is 0, resume all
threads, but where do we step?  How would you like to see us specify
this - I used Hs, a new step packet taking a thread argument might work
too... etc.

There's also the question of whether any other simulators or targets
handle this, and how they behave; I'm not familiar with them.  Do they
treat "HcTID, s" as single-step-one-thread-only?  I guess they probably
do.

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

Yes, that has the general model that I'm looking for, but this requires
some protocol changes - the protocol would be async-only.  It wouldn't
make sense as a synchronous protocol.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer