This is the mail archive of the
mailing list for the GDB project.
Re: Is stub support for the 's' packet optional or required?
Like I said, take it with a grain of salt.
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?
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 :-).
Again it's theory.
# 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.
I think it is better if WFI is directly aware of the location of the
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
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.)