Logging as many info as possible using qemu-system

Issue

i'm trying to emulate a series of ARM firmwares using qemu-system. I'm starting off with a raspberry image to experiment a bit, and I wonder if there's a way to log every action that the (emulated) raspberry makese (eg. system calls). The command i'm using right now is

sudo qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -dtb versatile-pb.dtb -no-reboot -serial stdio -append "root=/dev/sda2 rootfstype=ext4 rw" -hda rpitest.qcow2 -net nic -net user -net tap,ifname=vnet0,script=no,downscript=no -trace guest_user_syscall,file=trace

but the file trace remains empty during execution. Do you have any advice? Thanks in advance :)

Solution

The 'guest_user_syscall' tracepoint is used only by the user-mode emulator (qemu-arm), not by the system emulator (qemu-system-arm), so it will never fire for your command line.

In general QEMU does not have a tracing system that will record all information about what the guest CPU is doing: QEMU's design favours "run correct code quickly", not "provide a lot of introspection and information about what possibly-buggy code is doing". The facilities that are available, in rough order of user convenience, are:

• the gdbstub. You can connect a remote gdb that knows about your target architecture to QEMU's gdbstub and do all the usual things like singlestep, set breakpoints, etc. Often the most 'user-friendly' way to debug guest code, especially during early bootup.
• tracepoints (loggable via -trace or also via a suboption of-d). You get whatever the authors of the device model code etc felt was useful, which varies a lot from device to device. Can be very helpful for debugging guest code that's interacting with a specific device, provided that the device model has tracepoints (or you are capable of adding them).
• the -d debug logging options. Mostly these are biased towards logging things that are easy to log and things that assist in debugging QEMU itself. You need some awareness of what QEMU does under the hood (and in particular the distinction between "translation time" and "runtime") to interpret them correctly, but they can be useful for figuring out what guest code is doing.
• TCG plugins: this is a relatively new feature provided by QEMU where you can write a C plugin which can "instrument" the emulated guest code. In theory this lets you do quite complex things such as count and classify executed instructions (for instance you could count syscall insns); however the API is pretty complicated and there are still some obvious missing pieces (for instance you can't write a plugin that traces all memory accesses).

Answered By - Peter Maydell