Re: [PATCH v6 23/25] tests: add plugin asserting correctness of discon event's to_pc

["Julian Ganz" <neither@nut.email>]

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