Remote protocol question: the documentation says '?' is not required, but maybe it is?

Remote protocol question: the documentation says '?' is not required, but maybe it is?

[Reuben Thomas]

In the GDB manual, section E.1 Overview about the Remote Protocol, there is
the following text:

At a minimum, a stub is required to support the ‘g’ and ‘G’ commands for
> register access, and the ‘m’ and ‘M’ commands for memory access. Stubs
> that only control single-threaded targets can implement run control with
> the ‘c’ (continue), and ‘s’ (step) commands. Stubs that support
> multi-threading targets should support the ‘vCont’ command. All other
> commands are optional.
>

In particular, this suggests that it is not necessary to support the '?'
command, which returns the most recent signal.

My simple remote stub indeed implements only 'g', 'G', 'm', 'M', 'c', 'd'
and 'k'. It also implements '?', and, on startup, sends a 'T' packet.

However, if I remove the implementation of '?', the following conversation
ensues with gdb:

putpacket:
> T0500:f4dff800;01:f4dff800;02:00400000;03:f580a200;04:00001000;05:00000000;06:f5805200;07:00001000;08:00000000;09:ffffffff;
> getpacket:
> qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+
> putpacket:
> getpacket: vMustReplyEmpty
> putpacket:
> getpacket: Hg0
> putpacket:
> getpacket: qTStatus
> putpacket:
> getpacket: ?
> putpacket:
> getpacket: qfThreadInfo
> putpacket:
> getpacket: qL1160000000000000000
> putpacket:
> getpacket: Hc-1
> putpacket:
> getpacket: qC
> putpacket:
> getpacket: qAttached
> putpacket:
> warning: Invalid remote reply:
>

and GDB hangs. It seems that it can't cope with my lack of reply to '?'.

Is this a bug in gdb, or should the documentation be updated? I'm using gdb
from recent master, commit 360f1cd72d; I have patched it to support my
architecture, but I've not touched remote.c or anything else to do with the
remote protocol.

On the other hand, as you can see from my list above, I do not implement
the 's' command, but this does not seem to be a problem. Again, is this an
error in the documentation?

-- 
https://rrt.sc3d.org

Re: Remote protocol question: the documentation says '?' is not required, but maybe it is?

[Christo Crause]

On Sun, Jul 19, 2020 at 9:09 PM Reuben Thomas via Gdb <gdb@sourceware.org>
wrote:

> In particular, this suggests that it is not necessary to support the '?'
> command, which returns the most recent signal.
>
> My simple remote stub indeed implements only 'g', 'G', 'm', 'M', 'c', 'd'
> and 'k'. It also implements '?', and, on startup, sends a 'T' packet.
>
> However, if I remove the implementation of '?', the following conversation
> ensues with gdb:
>
> putpacket:
> >
> T0500:f4dff800;01:f4dff800;02:00400000;03:f580a200;04:00001000;05:00000000;06:f5805200;07:00001000;08:00000000;09:ffffffff;
> > getpacket:
> >
> qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+
> > putpacket:
> > getpacket: vMustReplyEmpty
> > putpacket:
> > getpacket: Hg0
> > putpacket:
> > getpacket: qTStatus
> > putpacket:
> > getpacket: ?
> > putpacket:
> > getpacket: qfThreadInfo
> > putpacket:
> > getpacket: qL1160000000000000000
> > putpacket:
> > getpacket: Hc-1
> > putpacket:
> > getpacket: qC
> > putpacket:
> > getpacket: qAttached
> > putpacket:
> > warning: Invalid remote reply:
> >
>
> and GDB hangs. It seems that it can't cope with my lack of reply to '?'.
>

Reading E.3 suggests that the stop reply packet (S or T) is only expected
after gdb issued one of a few specific commands.  So my interpretation (I'm
no expert on the topic) is that your unsolicited T packet is confusing gdb.
It seems as if your debug log is from your gdbserver perspective, can you
also check the communication received on gdb side (set debug remote 1),
this may highlight the reply gdb is complaining about.

Re: Remote protocol question: the documentation says '?' is not required, but maybe it is?

[Reuben Thomas]

On Tue, 21 Jul 2020 at 11:22, Christo Crause <christo.crause@gmail.com>
wrote:


> Reading E.3 suggests that the stop reply packet (S or T) is only expected
> after gdb issued one of a few specific commands.  So my interpretation (I'm
> no expert on the topic) is that your unsolicited T packet is confusing gdb.
> It seems as if your debug log is from your gdbserver perspective, can you
> also check the communication received on gdb side (set debug remote 1),
> this may highlight the reply gdb is complaining about.
>

Thanks for getting back to me! I don't think you're right, for two reasons:
first, I am sending the T packet in response to 'c'. (Except the first
time, when of course I didn't get a command, but effectively this is the
stub returning from 'c'.) Secondly, I copied this code from sparc-stub.c in
the GDB sources.

Also, whether or not I send T does not affect GDB's behaviour. In fact, I
shortened my code by changing it to send an S packet instead, which also
works fine, but still GDB needs me to implement '?'. The "invalid remote
reply" is in response to the stub sending an empty reply to "?".

-- 
https://rrt.sc3d.org

Re: Remote protocol question: the documentation says '?' is not required, but maybe it is?

[Maciej W. Rozycki]

On Tue, 21 Jul 2020, Reuben Thomas via Gdb wrote:

> Also, whether or not I send T does not affect GDB's behaviour. In fact, I
> shortened my code by changing it to send an S packet instead, which also
> works fine, but still GDB needs me to implement '?'. The "invalid remote
> reply" is in response to the stub sending an empty reply to "?".

 FYI, I do believe `?' is indeed mandatory, as GDB needs to figure out the 
initial state of the remote target as it has connected to it, and there is 
no other way.  Documentation may be incomplete/incorrect here, and fallout 
from the lack of response (a protocol violation) might be better.

  Maciej

Re: Remote protocol question: the documentation says '?' is not required, but maybe it is?

[Christo Crause]

On Tue, Jul 21, 2020 at 1:34 PM Maciej W. Rozycki <macro@wdc.com> wrote:

> On Tue, 21 Jul 2020, Reuben Thomas via Gdb wrote:
>
> > Also, whether or not I send T does not affect GDB's behaviour. In fact, I
> > shortened my code by changing it to send an S packet instead, which also
> > works fine, but still GDB needs me to implement '?'. The "invalid remote
> > reply" is in response to the stub sending an empty reply to "?".
>
>  FYI, I do believe `?' is indeed mandatory, as GDB needs to figure out the
> initial state of the remote target as it has connected to it, and there is
> no other way.  Documentation may be incomplete/incorrect here, and fallout
> from the lack of response (a protocol violation) might be better.
>
>   Maciej
>

I've tested this (empty reply for the ? packet) in gdb 8.3 and it also
results in gdb hanging, in agreement with Reuben's observations.  I
therefore think Maciej is correct, the ? packet is required and should be
marked as mandatory.

Re: Remote protocol question: the documentation says '?' is not required, but maybe it is?

[Reuben Thomas]

On Tue, 21 Jul 2020 at 12:34, Maciej W. Rozycki <macro@wdc.com> wrote:

Thanks for chiming in!

On Tue, 21 Jul 2020, Reuben Thomas via Gdb wrote:
>
> > Also, whether or not I send T does not affect GDB's behaviour. In fact, I
> > shortened my code by changing it to send an S packet instead, which also
> > works fine, but still GDB needs me to implement '?'. The "invalid remote
> > reply" is in response to the stub sending an empty reply to "?".
>
>  FYI, I do believe `?' is indeed mandatory, as GDB needs to figure out the
> initial state of the remote target as it has connected to it, and there is
> no other way.


It seems to be more complicated than that. In principle, '?' isn't needed
in principle to figure out the initial state: the T packet, or in my
current case, the S packet tells GDB the signal, and yet GDB still asks for
it again with '?'. The signal that caused the remote to halt is not going
to change until the next 'c', so there's no need for GDB to ask for it
again; and yet it does.


>   Documentation may be incomplete/incorrect here, and fallout
> from the lack of response (a protocol violation) might be better.
>

I had a look at `remote.c`, and I found these lines in
`remote_target::start_remote` (currently around line 4700 in remote.c):

  /* Check whether the target is running now.  */
  putpkt ("?");

The reply is cached, and later parsed in `remote_target::wait_as`, which
then complains because it doesn't accept an empty answer (when TRAP or
signal 0 was the signal given to GDB, which is the case on startup).

It looks indeed as if not supporting '?' will mean trouble. Further, around
line 4580, we find:

  /* Ack any packet which the remote side has already sent.  */
  remote_serial_write ("+", 1);

so it looks as though the first packet the stub sends is ignored.
(Presumably it is not ignored in later rounds, when the remote really has
issued a 'c' command.)

-- 
https://rrt.sc3d.org

Re: Remote protocol question: the documentation says '?' is not required, but maybe it is?

[Maciej W. Rozycki]

On Tue, 21 Jul 2020, Reuben Thomas wrote:

> >  FYI, I do believe `?' is indeed mandatory, as GDB needs to figure out the
> > initial state of the remote target as it has connected to it, and there is
> > no other way.
> 
> It seems to be more complicated than that. In principle, '?' isn't needed
> in principle to figure out the initial state: the T packet, or in my
> current case, the S packet tells GDB the signal, and yet GDB still asks for
> it again with '?'. The signal that caused the remote to halt is not going
> to change until the next 'c', so there's no need for GDB to ask for it
> again; and yet it does.

 I take you mean a `T' or `S' stop reply, right?

 Well, such replies are only expected by GDB in response to specific 
packets, which are all listed at the top of Section E.3 "Stop Reply 
Packets".  If you issue an unsolicited stop reply from your debug stub, 
then at best GDB will ignore it and at worst GDB will get confused.

> It looks indeed as if not supporting '?' will mean trouble. Further, around
> line 4580, we find:
> 
>   /* Ack any packet which the remote side has already sent.  */
>   remote_serial_write ("+", 1);
> 
> so it looks as though the first packet the stub sends is ignored.

 Indeed, GDB may have connected to the remote stub, say, over a serial 
line, so stale data may have already been buffered by serial hardware or 
the OS and anything on the fly is not considered valid data until both 
ends have synchronised.

 HTH,

  Maciej

Re: Remote protocol question: the documentation says '?' is not required, but maybe it is?

[Reuben Thomas]

On Tue, 21 Jul 2020 at 20:34, Maciej W. Rozycki <macro@wdc.com> wrote:

> On Tue, 21 Jul 2020, Reuben Thomas wrote:
>
> > >  FYI, I do believe `?' is indeed mandatory, as GDB needs to figure out
> the
> > > initial state of the remote target as it has connected to it, and
> there is
> > > no other way.
> >
> > It seems to be more complicated than that. In principle, '?' isn't needed
> > in principle to figure out the initial state: the T packet, or in my
> > current case, the S packet tells GDB the signal, and yet GDB still asks
> for
> > it again with '?'. The signal that caused the remote to halt is not going
> > to change until the next 'c', so there's no need for GDB to ask for it
> > again; and yet it does.
>
>  I take you mean a `T' or `S' stop reply, right?
>
>  Well, such replies are only expected by GDB in response to specific
> packets, which are all listed at the top of Section E.3 "Stop Reply
> Packets".  If you issue an unsolicited stop reply from your debug stub,
> then at best GDB will ignore it and at worst GDB will get confused.
>

Sorry, I didn't explain this clearly enough before.

As you can see in section E.3, T is an allowed reply to the 'c' command.

As I explained in my previous message, the first packet that the debug stub
sends is discarded by gdb.

Therefore, the stub is only sending the T packet when it is allowed: the
first time, it is discarded, and every other time, it is in response to a
'c' command.

-- 
https://rrt.sc3d.org

Re: Remote protocol question: the documentation says '?' is not required, but maybe it is?

[Reuben Thomas]

On Tue, 21 Jul 2020 at 21:24, Reuben Thomas <rrt@sc3d.org> wrote:

> On Tue, 21 Jul 2020 at 20:34, Maciej W. Rozycki <macro@wdc.com> wrote:
>
>> On Tue, 21 Jul 2020, Reuben Thomas wrote:
>>
>> > >  FYI, I do believe `?' is indeed mandatory, as GDB needs to figure
>> out the
>> > > initial state of the remote target as it has connected to it, and
>> there is
>> > > no other way.
>> >
>> > It seems to be more complicated than that. In principle, '?' isn't
>> needed
>> > in principle to figure out the initial state: the T packet, or in my
>> > current case, the S packet tells GDB the signal, and yet GDB still asks
>> for
>> > it again with '?'. The signal that caused the remote to halt is not
>> going
>> > to change until the next 'c', so there's no need for GDB to ask for it
>> > again; and yet it does.
>>
>
As I mentioned earlier, gdb discards this first 'T' packet, so that
explains why it needs to send '?', even in principle. But that doesn't seem
to be relevant, as gdb always sends '?' at the start of a conversation.

Re: Remote protocol question: the documentation says '?' is not required, but maybe it is?

[Reuben Thomas]

On Tue, 21 Jul 2020 at 21:26, Reuben Thomas <rrt@sc3d.org> wrote:

> On Tue, 21 Jul 2020 at 21:24, Reuben Thomas <rrt@sc3d.org> wrote:
>
>> On Tue, 21 Jul 2020 at 20:34, Maciej W. Rozycki <macro@wdc.com> wrote:
>>
>>> On Tue, 21 Jul 2020, Reuben Thomas wrote:
>>>
>>> > >  FYI, I do believe `?' is indeed mandatory, as GDB needs to figure
>>> out the
>>> > > initial state of the remote target as it has connected to it, and
>>> there is
>>> > > no other way.
>>> >
>>> > It seems to be more complicated than that. In principle, '?' isn't
>>> needed
>>> > in principle to figure out the initial state: the T packet, or in my
>>> > current case, the S packet tells GDB the signal, and yet GDB still
>>> asks for
>>> > it again with '?'. The signal that caused the remote to halt is not
>>> going
>>> > to change until the next 'c', so there's no need for GDB to ask for it
>>> > again; and yet it does.
>>>
>>
> As I mentioned earlier, gdb discards this first 'T' packet, so that
> explains why it needs to send '?', even in principle. But that doesn't seem
> to be relevant, as gdb always sends '?' at the start of a conversation.
>

Just to eliminate this source of potential error, I adjusted my stub so
that when it first connects to gdb it does not send a packet. This does not
change the exchange with gdb in any way, except that the first packet from
the stub is not sent.

-- 
https://rrt.sc3d.org

Re: Remote protocol question: the documentation says '?' is not required, but maybe it is?

[Maciej W. Rozycki]

On Tue, 21 Jul 2020, Reuben Thomas wrote:

> Just to eliminate this source of potential error, I adjusted my stub so
> that when it first connects to gdb it does not send a packet. This does not
> change the exchange with gdb in any way, except that the first packet from
> the stub is not sent.

 Well, this corrects an actual protocol error.  Just as the name "reply" 
implies a stub is not supposed to send one when not requested by GDB, so 
not spontaneously upon accepting a connection from GDB either.

  Maciej

Re: Remote protocol question: the documentation says '?' is not required, but maybe it is?

[Reuben Thomas]

On Tue, 21 Jul 2020 at 22:19, Maciej W. Rozycki <macro@wdc.com> wrote:

> On Tue, 21 Jul 2020, Reuben Thomas wrote:
>
> > Just to eliminate this source of potential error, I adjusted my stub so
> > that when it first connects to gdb it does not send a packet. This does
> not
> > change the exchange with gdb in any way, except that the first packet
> from
> > the stub is not sent.
>
>  Well, this corrects an actual protocol error.


Indeed, and another version of gdb (or another debugger) might not be so
lenient.

-- 
https://rrt.sc3d.org