Re: RFC: Two small remote protocol extensions

Daniel Jacobowitz
2002-08-28T13:33:41Z

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