On 12/5/24 05:10, Julian Ganz wrote:
Hi Pierrick,

December 5, 2024 at 12:33 AM, "Pierrick Bouvier" wrote:
On 12/2/24 11:41, Julian Ganz wrote:

  +/*
  + * Copyright (C) 2024, Julian Ganz <neither@nut.email>
  + *
  + * License: GNU GPL, version 2 or later.
  + * See the COPYING file in the top-level directory.
  + */

Would be nice to include a description of the plugin here.

Agreed. I'll include one next time.

When booting an arm64 vm, I get this message:
Trap target PC mismatch
Expected: 23faf3a80
Encountered: 23faf3a84

  From what I understand, it means that the next_pc we have is incorrect.

Yes, this is indeed incorrect, and also a perfect example why this test
plugin exists. There are likely other errors lurking in target specific
code. Did you happen to also log interrupts? Do you remember what image
you used?

I used exactly this:

./build/qemu-system-aarch64 -plugin ./build/tests/tcg/plugins/libdiscons.so -smp 4 -M virt -d plugin -m 8G -device virtio-blk-pci,drive=root -drive if=none,id=root,file=./debianaarch64.img -M virt -cpu max,pauth=off -drive if=pflash,readonly=on,file=/usr/share/AAVMF/AAVMF_CODE.fd -drive if=pflash,file=./AAVMF_VARS.fd

The arm64 image is a vanilla debian stable I installed.
AAVMF* files come from qemu-efi-aarch64 debian package.


Btw: this also illustrates another issue I have with from_pc: we can
test the behavior for to_pc, but doing this meaningfully for from_pc
via a plugin is next to impossible because the instruction it points to
is not observable via an exec callback. At least not in the general
case, even not if we only consider a single type of event.


We can store the next_expected pc for each instruction (from current_instruction + insn_length), and we should be able to compare that with the expected from_pc.
This is mostly what contrib/plugins/cflow.c does.

With that, we can test from_pc.

Regards,
Julian Ganz


Reply via email to