Qemu Simple Backend Tracing Dosen'T Print Anything

What instructions does qemu trace?

QEMU's "in_asm" logging is not a log of executed instructions. It logs every time an instruction is translated (ie when QEMU generates a bit of host code corresponding to it). That translation is then cached and if the guest loops around and executes the same instruction again QEMU will simply re-use the same translation, and so it won't be logged by in_asm. "in_asm reports many fewer instructions" is therefore expected.

Logging every executed instruction via the -d options is a bit tricky -- you need to look at the 'cpu' and 'exec' traces, to use the 'nochain' suboption of -d to disable a QEMU optimisation that would otherwise result in some blocks not being logged, to use '-singlestep' to force one instruction per block, and also to account for a few corner cases where we print an execution trace and then don't actually execute the instruction. This is because the -d option is not intended as a way for users to introspect the behaviour of their program -- it is a debug option intended to allow debugging of what QEMU and the guest program are doing together, and so it prints information that requires a little understanding of QEMU internals to interpret correctly.

You might find it simpler to write a QEMU "plugin" instead: https://qemu.readthedocs.io/en/latest/devel/tcg-plugins.html -- this is an API designed to be fairly straightforward to write instrumentation like "count instructions executed". If you're lucky then one of the sample plugins might even
be sufficient for your purposes.

Displaying each assembly instruction executed in gdb

The following should do what you asked for:

# not strictly required, but you'll likely want the log anyway
(gdb) set logging on

# ask gdb to not stop every screen-full
(gdb) set height 0

(gdb) while 1
 > x/i $pc
 > stepi
 > end

However, this approach to debugging will likely prove futile: there are simply too many instructions executed even in most trivial programs.

A better approach might be to run the program until crash, attempt to understand what current function is doing and who calls it, and setting breakpoints appropriately.

On x86, you can often deduce function boundaries even in fully stripped executable.

Another thing you'll want to look at is strace/truss output, so you can see what system calls immediately precede the crash point.

Running a program written for freeRTOS (RTOS) in virtualmachine as a binary

For virtual box, you will need a binary of freeRTOS that is x86 or amd64 compatible. Check if this is of any benefit for you.

You can check this link, as I understand it's a simulator for freeRTOS which may enable you to test it without a virtual machine.

For QEMU, check this link

---

Related Topics