Hi Alex, September 25, 2025 at 12:41 PM, "Alex Bennée" wrote: > "Julian Ganz" <[email protected]> writes: > > September 23, 2025 at 10:29 PM, "Julian Ganz" wrote: > > > September 22, 2025 at 12:11 PM, "Julian Ganz" wrote: > > > > (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?
We _do_ observe the exception occuring, we just don't observe it being handled. Instead we observe the result after the trap handler returned. And that's probably what we want for user-mode emulation where we don't have any introspection into the trap handler's execution. What trips the testing plugin is that it expects observing the trap handler, and there's currently nothing we can do here instead of just giving up when running user-mode emulation. We can introduce actual tests for user-mode emulation again in the future, should we introduce a discontinuity type for trap handler return (e.g. for RISC-V's `mret`). > In fact I think you could probably generate the event at > qemu_plugin_vcpu_syscall()? I could, but that would be somewhat separate from the trap related stuff. Syscalls would likely qualify as a separate, new discontinuity type similar to host calls. > 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. I still need to distinguish between discontinuity types, and that does (currently) require target specific knowledge. Or maybe I misunderstood what you were trying to say? Regards, Julian
