This is the mail archive of the
mailing list for the GDB project.
Re: Is stub support for the 's' packet optional or required?
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
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
> >> [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.