Re: Is stub support for the 's' packet optional or required?

[Andrew Cagney <ac131313@redhat.com>]

> On Feb 18,  4:07pm, Andrew Cagney wrote:
> 
> 
>> # FIXME/cagney/2001-01-18: This should be split in two.  A target method 
>> that indicates if the target needs software single step.  An ISA method 
>> to implement it.
> 
> 
> This one puzzles me.  How can gdb find out if a target (e.g. remote stub)
> can single step without first attempting the operation?

Like I said, take it with a grain of salt.

The key thing here is that it is the target, and not the architecture, 
that is consulted first.  It could be handled internally by target 
resume, or a new method target_singlestep_p().

For remote, target_singlestep_p() might initially return false but then, 
when it realises the mistake, return true.  WFI would recover from this 
foo-bar since the first wait would just return TARGET_WAITKIND_SPURIOUS 
(or perhaphs TARGET_WAITKIND_LOOK_TRY_CONTINUE :-).

>> # FIXME/cagney/2001-01-18: This should be replaced with something that 
>> inserts breakpoints using the breakpoint system instead of blatting 
>> memory directly (as with rs6000).
> 
> 
> I agree with this and am looking into doing it.

Again it's theory.

I think it is better if WFI is directly aware of the location of the 
single-step breakpoints.

Per your comments each target_resume() can also handle this directly (I 
think, long ago stu grossman suggested something like that?).  For 
remote.c though, this may not be possible.  After resuming the target it 
needs to return to the event loop.  Then, when a target event (eg "" or 
"T...") arrives, it processes it realizing that the "s" packet was 
ignored.  This also means that each generic target (proc, ptrace, 
remote) needs to be separatly modified.

>> # FIXME/cagney/2001-01-18: The logic is backwards.  It should be asking 
>> if the target can single step.  If not, then implement single step using 
>> breakpoints.
> 
> 
> It seems to me that this could be rolled into the first comment, above.

Yes.

>> (All taken with a grain of salt.)
> 
> 
> After (re)reading these comments, I came up with a different strategy
> (which I'm presently rethinking).  Instead of asking the target if
> it can single step, it might be better to push the SOFTWARE_SINGLE_STEP
> invocation down to the bottom-most target resume() (i.e, child_resume()
> for many natives).  At the moment, it's in resume() in infrun.c. 
> (There is also a call which removes the breakpoints, but, presumably
> if we get things using the breakpoint system, this can be replaced
> with something better.)

Andrew