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

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

[Ian Jiang]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

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

Trace (piece)
===========
IN:
0x0000000081150000:  00259eb7  lui t4,2461696
0x0000000081150004:  00099b37  lui s6,626688
0x0000000081150008:  01db3023  sd t4,0(s6)
0x000000008115000c:  00008067  ret

pc        0000000081150000
x1/ra    000000008000056c

IN:
0x0000000080003da0: 10503023  sd t0,256(zero)
...


QEMU version
===========
upstream tag v4.2.0

--
Ian Jiang

[-- Attachment #2: Type: text/html, Size: 1201 bytes --]

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

[Bin Meng]

On Wed, Jan 8, 2020 at 5:23 PM Ian Jiang <ianjiang.ict@gmail.com> 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.

I don't get this. is not at address A but at address B, but you wrote
A and B exactly the same?

> 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
>
> Trace (piece)
> ===========
> IN:
> 0x0000000081150000:  00259eb7  lui t4,2461696
> 0x0000000081150004:  00099b37  lui s6,626688
> 0x0000000081150008:  01db3023  sd t4,0(s6)
> 0x000000008115000c:  00008067  ret
>
> pc        0000000081150000
> x1/ra    000000008000056c
>
> IN:
> 0x0000000080003da0: 10503023  sd t0,256(zero)
> ...
>
>
> QEMU version
> ===========
> upstream tag v4.2.0
>

Regards,
Bin

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

[Peter Maydell]

On Wed, 8 Jan 2020 at 09:23, Ian Jiang <ianjiang.ict@gmail.com> 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