[Top][All Lists]

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

Re: riscv: How to debug a wrong pc after executing ret instruction?

From: Peter Maydell
Subject: Re: riscv: How to debug a wrong pc after executing ret instruction?
Date: Wed, 8 Jan 2020 15:34:11 +0000

On Wed, 8 Jan 2020 at 09:23, Ian Jiang <address@hidden> wrote:
> Problem
> ======
> The next instruction after executing "ret" (i.e. jalr x0, 0(x1)) is not at 
> 0x000000008000056c (x1/ra) as expected,  but at  0x000000008000056c.
> How to debug this issue? Any suggestion is appreciated.
> QEMU command
> =============
> qemu-system-riscv64 -nographic -machine virt -kernel my-test.elf -smp 1 -d 
> in_asm,cpu

You are probably being confused by the tracing. 'in_asm' tracing traces the
instructions when they are *translated*, not when they are *executed*.
QEMU translates blocks of instructions at a time, and it caches the results,
so if the guest binary re-executes a set of instructions you won't see any
in_asm tracing at all for that. To see tracing that happens at execution
time you can try the 'exec' or 'cpu' tracing (this produces a lot of output
so it's slow). You may also want 'nochain' which suppresses an optimisation
where we directly link blocks of translated code (which coincidentally
means the 2nd linked block won't appear in the trace).

Basically -d tracing traces things that are easy for QEMU to debug;
to successfully interpret it you need to have some idea of what
QEMU is doing under the hood.

-- PMM

reply via email to

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