Due to how we emulate the guest signal handlers, we do the state setup
in the real host signal handler, then we jump out after state setup.
This was causing a situation where we were setting up the guest signal
handler state with the correct sa_mask.
Then after setting up the guest state we would leave the FEX signal
handler, restoring the signal mask to our original mask.
Instead now as we are setting up the guest state, we save our host
signal mask. Then on signal handler return we modify our host signal
mask to match what the guest wants.
Once we hit our sigreturn emulation we then restore the original signal
mask.
This looks to improve some stability problems regarding how wine uses
signals but it still doesn't fix the gvisor test sadly.
We were using the glibc context structure layout which doesn't match
what the kernel is doing.
Switches over to allocating fpstate independentally of the ucontext_t,
then pointing to it from uc_mcontext how we're supposed to.
glibc uses the __fpregs_mem region for other purposes.
This also fixes xmm state being stored on the 32-bit side, and also
fixes SIGALRM and SIGVTALRM siginfo overwriting structure data.
On 32-bit we can't just memcpy the siginfo_t over because the sizes
don't match. Throw a message instead.
Initially this was a small hack to work around sigqueueinfo sending over
siginfo_t. Now this is unnecessary and would crash if an application
used sigqueueinfo to a signal without the SIGINFO flag.
This isn't quite a 100% clean sweep of IWYU.
There are some false positives where clang fails.
Additionally there are still a few missed in the frontend side of things
that I didn't get to
This is working towards getting the stack frame for guest signals being
pushed over to the Frontend.
Still some more work to do but this is the first step that can be split
up.
In the case of SRA plus a signal not using siginfo then we were not
spilling SRA registers.
In this case we would then shift the signal frame and fill the guest
context with garbage register data.
This would potentially cause some issues but haven't noticed anything
outside outside of my test applications.
Hangover currently abuses the syscall op for thunking purposes.
Very likely this will be changed in the future but for now make sure to
support that use case.
This was using the implicit thread TLS object. All users of this
have access to the thread object directly.
Use that instead. Fixes a subtle bug were the frontend could be trying
to do a callback and TLS sections weren't correctly set.
This always returns success and for easier state management, just return
our parent thread.
Frontend needs full visibility of this state anyway for thread
management.
si_addr is set to the address that is trying to be accessed, not the RIP
that is trying to access it.
We just need to copy our host value over for this.
SIGFPE and SIGILL we still don't have a good answer for.
We were checking the PC after we set the new location in the data
structure.
Didn't matter for x86-64 since it doesn't use SRA but it does matter for
ARM.
Now on signal while in JIT code it will spill correctly
MOVS, LODS, and STOS ops are only documented to support the REP prefix.
These instructions actually repeat correctly with the REPNE prefix as
well.
Behaviour is the same.
Fixes POD Gold
32-bit doesn't store XMM registers 8-15 since they don't exist there.
This technically falls under the "reserved" slot so applications can't
rely on them to not be written.
Saves us a bit of CPU overhead at the very least
There are two checks to the alt stack that the signal handler needs to
check.
First it needs to check if the signal handler was registered with teh
flag SA_ONSTACK.
Then it needs to check if the alt stack is actually enabled by not
having flag SS_DISABLE.
Additionally, 32-bit x86 doesn't have a redzone so stop offsetting by
128
We were failing to store the updated ESP on 32-bit.
On 64-bit or CPL change (which we don't support) the stack pointer is
pulled from the frame.
This resolves an issue in wine's 32-bit loader where it was getting zero
for one of the context pointers since the stack pointer wasn't adjusted
This information is only ever going to be offline. Will be useful for multiple reasons.
1) Searching for split lock usage in applications, which can be a programming bug.
a) This isn't visible on AMD systems and on Intel is a fairly new linux feature
2) Having more information about when an application breaks.
3) Useful for some minor profiling for devs looking for statistical data
A decent amount of this was broken.
To the point that the ABI was incorrect even, causing 32-bit signals to completely crash in most instances.
This is enough to get my 32-bit signal handler test application to work and basic SIGUSR behaviour
Ryan Houdek