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. Regards, Julian Ganz