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 > > 🕙17:35:52 alex@draig:tests/tcg/i386-linux-user on review/tcg-discon-v6 > > [$!?] [🔴 USAGE] > > ✗ > > > > although it never gets to the point of reporting what failed: > > > > Thread 1 "qemu-i386" hit Breakpoint 1, __GI_abort () at ./stdlib/abort.c:72 > > warning: 72 ./stdlib/abort.c: No such file or directory > > (gdb) bt > > #0 __GI_abort () at ./stdlib/abort.c:72 > > #1 0x00007ffff630874d in report_mismatch (pc_name=0x7ffff630a220 "target", > > vcpu_index=0, type=QEMU_PLUGIN_DISCON_EXCEPTION, last=134574955, > > expected=134574953, > > encountered=134574955) at ../../tests/tcg/plugins/discons.c:89 > > #2 0x00007ffff6308c0d in insn_exec (vcpu_index=0, userdata=0x0) at > > ../../tests/tcg/plugins/discons.c:132 > > #3 0x00007fffea431114 in code_gen_buffer () > > #4 0x000055555577b0a6 in cpu_tb_exec (cpu=0x529000005200, > > itb=0x7fffea431000 <code_gen_buffer+200659>, tb_exit=0x7ffff49c9530) at > > ../../accel/tcg/cpu-exec.c:438 > > #5 0x000055555577c92f in cpu_loop_exec_tb (cpu=0x529000005200, > > tb=0x7fffea431000 <code_gen_buffer+200659>, pc=134574955, > > last_tb=0x7ffff49c9540, tb_exit=0x7ffff49c9530) > > at ../../accel/tcg/cpu-exec.c:871 > > #6 0x000055555577d151 in cpu_exec_loop (cpu=0x529000005200, > > sc=0x7ffff483a740) at ../../accel/tcg/cpu-exec.c:981 > > #7 0x000055555577d2fe in cpu_exec_setjmp (cpu=0x529000005200, > > sc=0x7ffff483a740) at ../../accel/tcg/cpu-exec.c:998 > > #8 0x000055555577d4c8 in cpu_exec (cpu=0x529000005200) at > > ../../accel/tcg/cpu-exec.c:1024 > > #9 0x00005555557bfc83 in cpu_loop (env=0x529000007dd0) at > > ../../linux-user/i386/cpu_loop.c:215 > > #10 0x00005555558ee3e1 in main (argc=4, argv=0x7fffffffe688, > > envp=0x7fffffffe6b0) at ../../linux-user/main.c:1038 > > (gdb) f 1 > > #1 0x00007ffff630874d in report_mismatch (pc_name=0x7ffff630a220 "target", > > vcpu_index=0, type=QEMU_PLUGIN_DISCON_EXCEPTION, last=134574955, > > expected=134574953, > > encountered=134574955) at ../../tests/tcg/plugins/discons.c:89 > > 89 g_abort(); > > (gdb) p report > > $1 = (GString *) 0x50300002bf00 > > (gdb) p report->Str > > There is no member named Str. > > (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. Regards, Julian
