From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Joel Stanley" <joel@jms.id.au>
Cc: "Matheus Tavares Bernardino" <quic_mathbern@quicinc.com>,
<alex.bennee@linaro.org>, <fbarrat@linux.ibm.com>,
<qemu-devel@nongnu.org>, <qemu-stable@nongnu.org>
Subject: Re: [PATCH] gdbstub: Fix client Ctrl-C handling
Date: Sun, 30 Jul 2023 19:43:26 +1000 [thread overview]
Message-ID: <CUFEQY5EGPAK.BFTBD2ZPJV5A@wheely> (raw)
In-Reply-To: <CACPK8Xf-fa4qKZpgg4FvMkgzwbqgP1rh4=qLmv12N1JFcBn3Cg@mail.gmail.com>
On Wed Jul 26, 2023 at 4:35 PM AEST, Joel Stanley wrote:
> On Wed, 12 Jul 2023 at 02:12, Nicholas Piggin <npiggin@gmail.com> wrote:
> >
> > On Tue Jul 11, 2023 at 9:03 PM AEST, Matheus Tavares Bernardino wrote:
> > > > Nicholas Piggin <npiggin@gmail.com> wrote:
> > > >
> > > > diff --git a/gdbstub/gdbstub.c b/gdbstub/gdbstub.c
> > > > index 6911b73c07..ce8b42eb15 100644
> > > > --- a/gdbstub/gdbstub.c
> > > > +++ b/gdbstub/gdbstub.c
> > > > @@ -2051,8 +2051,17 @@ void gdb_read_byte(uint8_t ch)
> > > > return;
> > > > }
> > > > if (runstate_is_running()) {
> > > > - /* when the CPU is running, we cannot do anything except stop
> > > > - it when receiving a char */
> > > > + /*
> > > > + * When the CPU is running, we cannot do anything except stop
> > > > + * it when receiving a char. This is expected on a Ctrl-C in the
> > > > + * gdb client. Because we are in all-stop mode, gdb sends a
> > > > + * 0x03 byte which is not a usual packet, so we handle it specially
> > > > + * here, but it does expect a stop reply.
> > > > + */
> > > > + if (ch != 0x03) {
> > > > + warn_report("gdbstub: client sent packet while target running\n");
> > > > + }
> > > > + gdbserver_state.allow_stop_reply = true;
> > > > vm_stop(RUN_STATE_PAUSED);
> > > > } else
> > > > #endif
> > >
> > > Makes sense to me, but shouldn't we send the stop-reply packet only for
> > > Ctrl+C/0x03?
> >
> > Good question.
> >
> > I think if we get a character here that's not a 3, we're already in
> > trouble, and we eat it so even worse. Since we only send a stop packet
> > back when the vm stops, then if we don't send one now we might never
> > send it. At least if we send one then the client might have some chance
> > to get back to a sane state. And this does at least take us back to
> > behaviour before the stop filtering patch.
> >
> > Could go further and only stop the machine if it was a 3, or send a
> > stop packet even if we were stopped, etc. but all that get further from
> > a minimal fix.
>
> I was taking a look at -rc1 and it looks like this hasn't made it in.
> Is it something we want to propose including?
>
> As a user of qemu I'd vote for it to go in.
I think it should, gdb is hardly usable without it.
Thanks,
Nick
next prev parent reply other threads:[~2023-07-30 9:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 8:59 [PATCH] gdbstub: Fix client Ctrl-C handling Nicholas Piggin
2023-07-11 11:03 ` Matheus Tavares Bernardino
2023-07-12 2:11 ` Nicholas Piggin
2023-07-26 6:35 ` Joel Stanley
2023-07-30 9:43 ` Nicholas Piggin [this message]
2023-07-31 6:58 ` Joel Stanley
2023-07-31 13:59 ` Peter Maydell
2023-08-01 20:05 ` Philippe Mathieu-Daudé
2023-08-01 18:40 ` Matheus Tavares Bernardino
2023-08-08 22:56 ` Richard Henderson
2023-08-10 10:05 ` Alex Bennée
2023-07-12 2:13 ` Nicholas Piggin
2023-07-12 10:39 ` Michael Tokarev
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=CUFEQY5EGPAK.BFTBD2ZPJV5A@wheely \
--to=npiggin@gmail.com \
--cc=alex.bennee@linaro.org \
--cc=fbarrat@linux.ibm.com \
--cc=joel@jms.id.au \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=quic_mathbern@quicinc.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;
as well as URLs for NNTP newsgroup(s).