Re: RFC: Two small remote protocol extensions

Andrew Cagney
2002-08-28T04:07:08Z

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

:-)