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

On Tue, 21 Jul 2020 at 12:34, Maciej W. Rozycki <[email protected]> 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