This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?
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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]