All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé via" <qemu-devel@nongnu.org>
To: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Liviu Ionescu" <ilg@livius.net>
Subject: Re: [PATCH 1/2] gdbstub: Don't use GDB syscalls if no GDB is attached
Date: Sun, 29 May 2022 13:06:10 +0200	[thread overview]
Message-ID: <6d649290-d619-ef2d-5d32-c0fca95f8d64@amsat.org> (raw)
In-Reply-To: <20220526190053.521505-2-peter.maydell@linaro.org>

On 26/5/22 21:00, Peter Maydell wrote:
> In two places in gdbstub.c we look at gdbserver_state.init to decide
> whether we're going to do a semihosting syscall via the gdb remote
> protocol:
>   * when setting up, if the user didn't explicitly select either
>     native semihosting or gdb semihosting, we autoselect, with the
>     intended behaviour "use gdb if gdb is connected"
>   * when the semihosting layer attempts to do a syscall via gdb, we
>     silently ignore it if the gdbstub wasn't actually set up
> 
> However, if the user's commandline sets up the gdbstub but tells QEMU
> to start rather than waiting for a GDB to connect (eg using '-s' but
> not '-S'), then we will have gdbserver_state.init true but no actual
> connection; an attempt to use gdb syscalls will then crash because we
> try to use gdbserver_state.c_cpu when it hasn't been set up:
> 
> #0  0x00007ffff6803ba8 in qemu_cpu_kick (cpu=0x0) at ../../softmmu/cpus.c:457
> #1  0x00007ffff6c03913 in gdb_do_syscallv (cb=0x7ffff6c19944 <common_semi_cb>,
>      fmt=0x7ffff7573b7e "", va=0x7ffff56294c0) at ../../gdbstub.c:2946
> #2  0x00007ffff6c19c3a in common_semi_gdb_syscall (cs=0x7ffff83fe060,
>      cb=0x7ffff6c19944 <common_semi_cb>, fmt=0x7ffff7573b75 "isatty,%x")
>      at ../../semihosting/arm-compat-semi.c:494
> #3  0x00007ffff6c1a064 in gdb_isattyfn (cs=0x7ffff83fe060, gf=0x7ffff86a3690)
>      at ../../semihosting/arm-compat-semi.c:636
> #4  0x00007ffff6c1b20f in do_common_semihosting (cs=0x7ffff83fe060)
>      at ../../semihosting/arm-compat-semi.c:967
> #5  0x00007ffff693a037 in handle_semihosting (cs=0x7ffff83fe060)
>      at ../../target/arm/helper.c:10316
> 
> You can probably also get into this state via some odd
> corner cases involving connecting a GDB and then telling it
> to detach from all the vCPUs.
> 
> Abstract out the test into a new gdb_attached() function
> which returns true only if there's actually a GDB connected
> to the debug stub and attached to at least one vCPU.
> 
> Reported-by: Liviu Ionescu <ilg@livius.net>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> Silently doing nothing in gdb_do_syscallv(), never calling the
> callback function, is kind of dodgy.  But it's what the code is doing
> already, and besides it's not clear what we should do if the user
> specifically says "semihosting calls via the gdb stub" and then
> doesn't connect gdb...

When using a JTAG probe as GDB monitor, you get an error the probe
can't get initialized. If the probe gets disconnected while running
then the semihosting calls are executed but don't do anything (or
return default errno).

Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>


  reply	other threads:[~2022-05-29 11:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-26 19:00 [PATCH 0/2] gdbstub: don't crash if no gdb attached and gdb syscall attempted Peter Maydell
2022-05-26 19:00 ` [PATCH 1/2] gdbstub: Don't use GDB syscalls if no GDB is attached Peter Maydell
2022-05-29 11:06   ` Philippe Mathieu-Daudé via [this message]
2022-06-09 20:01   ` Luc Michel
2022-05-26 19:00 ` [PATCH 2/2] semihosting/config: Merge --semihosting-config option groups Peter Maydell
2022-06-09 20:02   ` Luc Michel
2022-06-10 13:04 ` [PATCH 0/2] gdbstub: don't crash if no gdb attached and gdb syscall attempted Peter Maydell
2022-06-10 14:40   ` 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=6d649290-d619-ef2d-5d32-c0fca95f8d64@amsat.org \
    --to=qemu-devel@nongnu.org \
    --cc=alex.bennee@linaro.org \
    --cc=f4bug@amsat.org \
    --cc=ilg@livius.net \
    --cc=peter.maydell@linaro.org \
    --cc=richard.henderson@linaro.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.