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

[Peter Maydell]

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.

thanks
-- PMM