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

Andrew Cagney
2003-02-18T21:03:03Z

> On Tue, Feb 18, 2003 at 09:29:58AM -0700, Kevin Buettner wrote:
>
>> On Feb 17, 9:04pm, Andrew Cagney wrote:
>>
>
>> > If GDB implements software single step, then the `s' packet is never
>> > used. Consequently, requiring the unconditional implementation of "s"
>> > makes little sense.

Kevin wrote:

>> What about the situation where GDB implements software single step AND
>> the stub implements the 's' packet? Shouldn't GDB at least attempt to
>> see if the stub supports the 's' packet before deciding to never send
>> it?

It should but the interaction is weird. remote.c doesn't see the ""
reply until target_wait() is called. This means that the target_wait()
method would need to be modified to handle this. I guess it could
record this and then return immedatly with a TARGET_WAITKIND_SPURIOUS.
Kind of vaguely like how some of the other packets are handled.

But note, I'm guessing. Just having commands to disable it would be a
good first draft.

Oh, and yes. I really have seen targets that neither had h/w single
step nor had the space to implement s/w single step locally.

> In my humble opinion, SOFTWARE_SINGLE_STEP should affect native code
> and not remote;

No. The relevant comments read:

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

(All taken with a grain of salt.)

So, from the point of view of GDB's architecture, there is no difference.

> I'm much too intimidated by the stop and resume logic
> to actually change it myself, though. If there were less global state
> around infrun this might be easier.

Sigh.

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

Andrew