That was a complete misdiaagnsis. The IRET works fine in user space, at
the lowest privlege level.
The wrong thread is not restarted. The correct thread continues
execution, at the correct address, but with the wrong thread-local data.
Thread-local data is accessed via the segment loaded in the f
Be aware that most of the regression test failures are caused by lack of
ptrace() support.
The wine traces above show one of these cases. I will provide traces of
an actual relevant failure.
However the failure to restart the correct thread is in some way related
to the use of iret in set_full_cp
Public bug reported:
When trying to run wine (latest devel from git) regression tests for
ntdll in a statically linked qemu-i386 (commit
392b9a74b9b621c52d05e37bc6f41f1bbab5c6f8) on arm32 (raspberry pi 4) in a
debian buster chroot, the exception tests fail at the first test with an
infinite except
I have identified the core issue:
Synchronous exceptions/traps in linux-user/i386/cpu_loop.c are handled as a
return value from cpu_exec().
cpu_exec() resets exception_index to -1 in cpu_handle_exception()
This means that queue_signal() (called from gen_signal() in the cpu
loop) does not store
Public bug reported:
QEMU development version, git commit
74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in
5.2.0 generally.
Certain 16-bit windows programs crash WINE under QEMU linux-user with:
0084:err:seh:segv_handler Got unexpected trap -1
wine: Unhandled illegal instruc
