"Julian Ganz" <[email protected]> writes: (add Richard to Cc)
> September 23, 2025 at 10:29 PM, "Julian Ganz" wrote: >> September 22, 2025 at 12:11 PM, "Julian Ganz" wrote: >> > September 21, 2025 at 6:46 PM, "Alex Bennée" wrote: >> > This is firing on: >> > >> > 🕙17:35:50 alex@draig:tests/tcg/i386-linux-user on review/tcg-discon-v6 >> > [$!?] >> > ➜ make run-plugin-catch-syscalls-with-libdiscons.so V=1 >> > timeout -s KILL --foreground 120 env >> > QEMU=/home/alex/lsrc/qemu.git/builds/sanitisers/qemu-i386 >> > /home/alex/lsrc/qemu.git/builds/sanitisers/qemu-i386 -plugin >> > ../plugins/libdiscons.so -d plugin -D >> > catch-syscalls-with-libdiscons.so.pout catch-syscalls > >> > run-plugin-catch-syscalls-with-libdiscons.so.out >> > Aborted >> > make: *** [Makefile:226: run-plugin-catch-syscalls-with-libdiscons.so] >> > Error 134 <snip> >> > (gdb) p report->str >> > $2 = (gchar *) 0x51100001fbc0 "Discon target PC mismatch on VCPU >> > 0\nExpected: 8057369\nEncountered: 805736b\nExecuted Last: 805736b\nEvent >> > type: exception\n" >> > (gdb) >> > >> > I think this is where it is going wrong: >> > >> > IN: _dl_early_allocate >> > 0x0805736b: 89 c2 movl %eax, %edx >> > 0x0805736d: 8d 1c 28 leal (%eax, %ebp), %ebx >> > 0x08057370: 89 c8 movl %ecx, %eax >> > 0x08057372: cd 80 int $0x80 >> > >> > Thanks! I'll have a closer look. >> > >> I probably didn't configure the target I need for this test on my >> private machine (which uses musl, so some targets are awkward). > > Turned out I just ran `make` in the wrong directory. > >> Could it >> be that this doesn't run in system emulation mode and the exception is >> somehow handled natively? I did not account for that possibility and I >> don't think I'll get the testing plugin to do anything meaningful >> outside system emulation. > > As expected the plugin ran in a qemu configuration in which the API does > not behave as expected. Which I could have figured out by the logs Alex > provided if I paid attention. Sorry for the noise. > > I added a check to the plugin that bails out if qemu does not run in > system emulation mode (which I thought I did, but that was only for the > contrib plugin). > > Even if we cannot test the API for user mode, it may still provide some > utility, so I suggest _just_ letting the testing plugin do nothing in > that case. In fact, I'm considering removing the check from the contrib > "traps" plugin now that I saw that the API _is_ triggered in user > mode. Is this just because we are missing the hooks into the linux-user run-loop? I assume int $0x80 is a syscall so we should report an exception type at that point? In fact I think you could probably generate the event at qemu_plugin_vcpu_syscall()? force_sig_fault() and force_sig() might be the other places that should be hooked. Or possibly handle_pending_signal() where all the other signals affect the code flow. I think that can avoid patching every arches run loop. Richard, WDYT? > > Regards, > Julian -- Alex Bennée Virtualisation Tech Lead @ Linaro
