qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible bug in Aarch64 single-stepping


From: Chris Howard
Subject: Re: Possible bug in Aarch64 single-stepping
Date: Sat, 7 May 2022 16:16:07 +0200

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 via email to

[Prev in Thread] Current Thread [Next in Thread]