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

[Kevin Buettner <kevinb@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?

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

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

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

As I said, I'm presently rethinking this.  The first step is to figure
out how to make software single step properly use the breakpoint
machinery.

> >> [For remote MIPS/Linux targets, I've found some cases where GDB's
> >> implementation of software singlestep causes some undesirable behavior
> >> when doing the 'stepi' operation through some code that's hit by a number
> >> of threads.  Yet, when software single step is implemented in the debug
> >> agent (and disabled in GDB), the debugging behavior is much more useful
> >> (and sensible).]
> > 
> > 
> > Is it just slow, or do different things actually happen?
> 
> It is just very slow.

I was actually seeing different behavior.

Kevin