qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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


  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 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).