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

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

[Kevin Buettner]

I've been told off-list that it is not required for a stub to
implement support for the 's' packet.  I was also told that the
documenation is wrong in this regard.  Specifically, it says:

    A stub is required to support the `g', `G', `m', `M', `c', and `s'
    commands.  All other commands are optional.

See
    http://sources.redhat.com/gdb/current/onlinedocs/gdb_32.html#SEC632
and
    http://world.std.com/~qqi/download/protocol.txt

(I often find the latter document to be the more useful of the two.)

I'd like to get other opinions regarding this matter.  Also, if it
really is the case that stubs are NOT required to implement support
for the 's' packet, then will all such stubs return the empty response
which indicates that there is no support for that particular packet?

Kevin

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

[Andrew Cagney]

> I've been told off-list that it is not required for a stub to
> implement support for the 's' packet.  I was also told that the
> documenation is wrong in this regard.  Specifically, it says:
> 
>     A stub is required to support the `g', `G', `m', `M', `c', and `s'
>     commands.  All other commands are optional.
> 
> See
>     http://sources.redhat.com/gdb/current/onlinedocs/gdb_32.html#SEC632
> and
>     http://world.std.com/~qqi/download/protocol.txt
> 
> (I often find the latter document to be the more useful of the two.)
> 
> I'd like to get other opinions regarding this matter.  Also, if it
> really is the case that stubs are NOT required to implement support
> for the 's' packet, then will all such stubs return the empty response
> which indicates that there is no support for that particular packet?

If GDB implements software single step, then the `s' packet is never
used.  Consequently, requiring the unconditional implementation of "s"
makes little sense.

Note though that, while a target that doesn't support the "s" packet
should return "" instead of "T...".  remote.c isn't exactly set up to
handle this - by the time it realizes it's got a problem it is a bit
late.  The step-out-of-range code tried to address this but in the
process created querky resume semantics.

Andrew

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

[Kevin Buettner]

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.

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?

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


Kevin

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

[Daniel Jacobowitz]

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

In my humble opinion, SOFTWARE_SINGLE_STEP should affect native code
and not remote; 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.

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Kevin Buettner]

On Feb 18, 11:51am, Daniel Jacobowitz wrote:

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

Different things happen.  Specifically, GDB was getting a SIGTRAP due to
one of the other threads hitting the software single step breakpoint. 
This meant that I was unable to step through the function that I was
attempting to debug when GDB was setting the software single step
breakpoints.  When I moved that functionality (software single step)
to the debug agent, I was able to step through the code of interest
without any problem.

Kevin

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

[Daniel Jacobowitz]

On Tue, Feb 18, 2003 at 01:06:28PM -0700, Kevin Buettner wrote:
> On Feb 18, 11:51am, Daniel Jacobowitz wrote:
> 
> > > [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?
> 
> Different things happen.  Specifically, GDB was getting a SIGTRAP due to
> one of the other threads hitting the software single step breakpoint. 
> This meant that I was unable to step through the function that I was
> attempting to debug when GDB was setting the software single step
> breakpoints.  When I moved that functionality (software single step)
> to the debug agent, I was able to step through the code of interest
> without any problem.

That's a bug in software single step handling; I bet it shows up now
too, just less often (because of latency changes).  I think it's as
simple as marking the single-step breakpoint thread-specific in the
normal way, but it might be a little more complicated...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Kevin Buettner]

On Feb 18,  3:23pm, Daniel Jacobowitz wrote:

> That's a bug in software single step handling; I bet it shows up now
> too, just less often (because of latency changes).  I think it's as
> simple as marking the single-step breakpoint thread-specific in the
> normal way, but it might be a little more complicated...

One of the problems with the single-step breakpoint machinery is that
it doesn't use the mechanisms in breakpoint.c, so it can't be marked
in the normal way (or in any way).  I'm presently looking at
introducing a new breakpoint type for software single step.  Once
that's done, I'm hoping that we can do as you suggest without having
to move the location of the SOFTWARE_SINGLE_STEP invocations.

The location of the invocations of SOFTWARE_SINGLE_STEP() may make
this hard to do though.  It is invoked to insert its breakpoint long
after breakpoints have been inserted.  Likewise, when removing
breakpoints, this happens much earlier than normal breakpoints are
removed.

Kevin

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

[Andrew Cagney]

> 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

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

[Kevin Buettner]

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

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

[Andrew Cagney]

> 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