From: Reuben Thomas <rrt@sc3d.org>
To: "Maciej W. Rozycki" <macro@wdc.com>
Cc: Christo Crause <christo.crause@gmail.com>,
Reuben Thomas via Gdb <gdb@sourceware.org>
Subject: Re: Remote protocol question: the documentation says '?' is not required, but maybe it is?
Date: Tue, 21 Jul 2020 19:51:15 +0100 [thread overview]
Message-ID: <CAOnWdog6XvD7H4WJ12CLREML5Zuru1RChrXfyjyah7S92MGhEw@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.21.2007211223570.24175@redsun52.ssa.fujisawa.hgst.com>
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
next prev parent reply other threads:[~2020-07-21 18:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-19 19:08 Reuben Thomas
2020-07-21 10:22 ` Christo Crause
2020-07-21 10:29 ` Reuben Thomas
2020-07-21 11:33 ` Maciej W. Rozycki
2020-07-21 16:35 ` Christo Crause
2020-07-21 18:51 ` Reuben Thomas [this message]
2020-07-21 19:34 ` Maciej W. Rozycki
2020-07-21 20:24 ` Reuben Thomas
2020-07-21 20:26 ` Reuben Thomas
2020-07-21 20:48 ` Reuben Thomas
2020-07-21 21:19 ` Maciej W. Rozycki
2020-07-21 21:23 ` Reuben Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOnWdog6XvD7H4WJ12CLREML5Zuru1RChrXfyjyah7S92MGhEw@mail.gmail.com \
--to=rrt@sc3d.org \
--cc=christo.crause@gmail.com \
--cc=gdb@sourceware.org \
--cc=macro@wdc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox