All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Howard <cvz185@web.de>
To: qemu-devel@nongnu.org
Subject: Re: Possible bug in Aarch64 single-stepping
Date: Sat, 7 May 2022 16:16:07 +0200	[thread overview]
Message-ID: <7988B475-EEC0-4574-B0E2-BB61738B8964@web.de> (raw)
In-Reply-To: <F1037D57-EB8E-43FA-A2C7-A43C45FEA82C@web.de>

On 7. May 2022, at 15:42, Chris Howard <cvz185@web.de> wrote:
> 
> Hi, I’m writing a simple debugger in assembly code for the Raspberry Pi 3B (in aarch64).
> 
> I’m using QEMU 7.0.0. Everything is running in EL1. (I have MDE and KDE set in MDSCR_EL1).
> 
> I’m coming across Unexpected Behaviour when playing with single-stepping:
> 
> It appears that single-stepping is enabled (ie. an exception is generated after every instruction) when the SS bit (bit-0) is set in MDSCR_EL1 and debug events are enabled in the CPSR (“D” bit clear) *** irrespective of whether the SS bit (bit-21) is set in CPSR or not ***.
> 
> I thought the SS bit (bit-21) needs to be set in CPSR for single-stepping to occur (and that it gets cleared whenever an exception is taken and needs to be reset if one wants to single-step again).
> 
> Have I misunderstood / misconfigured something, or is this a bug?
> 
> Attached is a minimal(ish) example:

Oh, and the exception occurs immediately (after the ERET), rather than after the instruction has been executed. It appears to be acting like a hardware breakpoint.


PS. In plain gdb (ie. no nice user interface) a large number (but not all) of the system registers gets displayed after each step. It would be nice if these were sorted in some way. At the moment they’re completely jumbled — not alphabetic, not grouped by EL, nor by “meaning”  (DBGWVR0_EL1 isn’t necessarily next to DBGWCR0_EL1).

Also, there are multiple (identical?) instances of “DBGBVR” and “DBGBCR” (and  “DBGWVR” and “DBGWCR”) rather than the expected “DBGWVR0_EL1”, “DBGWVR1_EL1” etc.

Would this be a QEMU or a GDB issue? Or isn’t it an issue at all? :-)

  reply	other threads:[~2022-05-07 14:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-07 13:42 Possible bug in Aarch64 single-stepping Chris Howard
2022-05-07 14:16 ` Chris Howard [this message]
2022-05-08 12:18   ` Peter Maydell
2022-05-08 12:19     ` Peter Maydell
2022-05-08 19:27     ` Possible bug in Aarch64 single-stepping [PATCH] Chris Howard
2022-05-10  9:59       ` Peter Maydell
2022-05-08 12:08 ` Possible bug in Aarch64 single-stepping Peter Maydell
2022-05-08 19:35   ` Chris Howard

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=7988B475-EEC0-4574-B0E2-BB61738B8964@web.de \
    --to=cvz185@web.de \
    --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.