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