Alexandre IOOSS <erdnaxe@crans.org> writes:
[[PGP Signed Part:Undecided]]
On 6/22/21 10:48 AM, Alex Bennée wrote:
Alexandre Iooss<erdnaxe@crans.org> writes:
[...]
+
+The execlog tool traces executed instructions with memory access. It can be
used
+for debugging and security analysis purposes.
We should probably mention that this will generate a lot of output.
Running the admittedly memory heavy softmmu memory test:
./aarch64-softmmu/qemu-system-aarch64 -D test.out -d plugin \
-plugin contrib/plugins/libexeclog.so \
-cpu max -serial mon:stdio -M virt \
-display none -semihosting-config chardev=serial0 \
-kernel ./tests/tcg/aarch64-softmmu/memory
generates a 8.6Gb text file. I suspect once this is merged you might
want to look at options to target the instrumentation at areas of
specific interest or abbreviate information.
Yes! In my downstream version I am triggering the beginning and the
end of trace acquisition by matching two virtual addresses of GPIO
device access. This works in my case because I'm also using the same
GPIO for triggering an oscilloscope, but maybe we would like to
upstream something more generic.
I'm still thinking about this (maybe for a later patch) but I believe
it would be nice to have the following:
- If no argument is given to the plugin, log everything.
- Allow the user to specify either a memory address, an instruction
virtual address or an opcode that would start the acquisition.
- Same to stop the acquisition.
Sounds reasonable to me.
This would look like this to start/stop acquisition using GPIO PA8 on
STM32VLDISCOVERY:
./arm-softmmu/qemu-system-arm -M stm32vldiscovery \
-kernel ./firmware.elf -d plugin \
-plugin libexeclog.so,arg=mem:1073809424,arg=mem:1073809424
I quite like the formats you can use for -dfilter, for example:
0x1000+0x100,0x2100-0x100,0x3000..0x3100
it might even be worth exposing qemu_set_dfilter_ranges as a helper
function to plugins to avoid copy and paste.