Hi Pierrick,
December 5, 2024 at 6:30 PM, "Pierrick Bouvier" wrote:
On 12/5/24 05:10, Julian Ganz wrote:
December 5, 2024 at 12:33 AM, "Pierrick Bouvier" wrote:
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.
Thanks! I will have a closer look and include a fix in the next iteration.
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.
I'm not confident that this will work reliably for branch, jump and
other "interesting" instructions. But I can have a closer look at the
cflow plugin and try to figure out how that plugin handles those cases.