From: "Alex Bennée" <alex.bennee@linaro.org>
To: Matheus Branco Borella <dark.ryu.550@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH] gdbstub: fixes cases where wrong threads were reported to GDB on SIGINT
Date: Tue, 27 Jun 2023 11:39:57 +0100 [thread overview]
Message-ID: <87y1k5yxiy.fsf@linaro.org> (raw)
In-Reply-To: <20230623181256.2596-1-dark.ryu.550@gmail.com>
Matheus Branco Borella <dark.ryu.550@gmail.com> writes:
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1725
>
> This fix is implemented by having the vCont handler set the value of
> `gdbserver_state.c_cpu` if any threads are to be resumed. The specific CPU
> is picked arbitrarily from the ones to be resumed, but it should be okay, as all
> GDB cares about is that it is a resumed thread.
>
> Keep in mind that because this patch overwrites `c_cpu`, it breaks cases where
> $vCont is used together with $Hc, so there might be more work to be
> done here.
That doesn't sound good. Is that a possible case or an invalid one
because we shouldn't see gdbs using both?
> It might also be the case that it breaking this, specifically, isn't of
> consequence, seeing as single stepping with $vCont already overwrites `c_cpu`
> anyway, so you could say the implementation already behaves oddly as far as
> mixing $vCont and $Hc is concerned.
It would be nice to have some unit tests for this behaviour to defend
it. See the various tests in tests/tcg that call $(GDB_SCRIPT) for
examples.
BTW you are missing a Signed-off-by: tag which we will need to take a
patch submission. See:
https://qemu.readthedocs.io/en/latest/devel/submitting-a-patch.html
> ---
> gdbstub/gdbstub.c | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/gdbstub/gdbstub.c b/gdbstub/gdbstub.c
> index be18568d0a..4f7ac5ddfe 100644
> --- a/gdbstub/gdbstub.c
> +++ b/gdbstub/gdbstub.c
> @@ -595,6 +595,15 @@ static int gdb_handle_vcont(const char *p)
> * or incorrect parameters passed.
> */
> res = 0;
> +
> + /*
> + * target_count and last_target keep track of how many CPUs we are going to
> + * step or resume, and a pointer to the state structure of one of them,
> + * respectivelly
> + */
> + int target_count = 0;
> + CPUState *last_target = NULL;
> +
> while (*p) {
> if (*p++ != ';') {
> res = -ENOTSUP;
> @@ -639,8 +648,10 @@ static int gdb_handle_vcont(const char *p)
> while (cpu) {
> if (newstates[cpu->cpu_index] == 1) {
> newstates[cpu->cpu_index] = cur_action;
> - }
>
> + target_count++;
> + last_target = cpu;
> + }
> cpu = gdb_next_attached_cpu(cpu);
> }
> break;
> @@ -657,6 +668,9 @@ static int gdb_handle_vcont(const char *p)
> while (cpu) {
> if (newstates[cpu->cpu_index] == 1) {
> newstates[cpu->cpu_index] = cur_action;
> +
> + target_count++;
> + last_target = cpu;
> }
>
> cpu = gdb_next_cpu_in_process(cpu);
> @@ -675,10 +689,25 @@ static int gdb_handle_vcont(const char *p)
> /* only use if no previous match occourred */
> if (newstates[cpu->cpu_index] == 1) {
> newstates[cpu->cpu_index] = cur_action;
> +
> + target_count++;
> + last_target = cpu;
> }
> break;
> }
> }
> +
> + /*
> + * if we're about to resume a specific set of CPUs/threads, make it so that
> + * in case execution gets interrupted, we can send GDB a stop reply with a
> + * correct value. it doesn't really matter which CPU we tell GDB the signal
> + * happened in (VM pauses stop all of them anyway), so long as it is one of
> + * the ones we resumed/single stepped here.
> + */
> + if (target_count > 0) {
> + gdbserver_state.c_cpu = last_target;
> + }
> +
> gdbserver_state.signal = signal;
> gdb_continue_partial(newstates);
Looks reasonable at first glance but I would like some tests.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2023-06-27 11:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-23 18:12 [PATCH] gdbstub: fixes cases where wrong threads were reported to GDB on SIGINT Matheus Branco Borella
2023-06-27 10:39 ` Alex Bennée [this message]
2023-07-06 23:50 ` Matheus Branco Borella
2023-08-04 18:26 ` [PATCH v2] " Matheus Branco Borella
2023-08-10 17:30 ` Alex Bennée
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=87y1k5yxiy.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=dark.ryu.550@gmail.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.