qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/2] docs/devel: tvg-plugins: add execlog plugin descripti


From: Alexandre IOOSS
Subject: Re: [PATCH v2 2/2] docs/devel: tvg-plugins: add execlog plugin description
Date: Tue, 22 Jun 2021 11:27:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2

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.

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 would like to hear other users opinion on this, because I fear I might implement something too specific.

Thanks,
-- Alexandre

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]