These syscall arguments are not laid out in a sane way.
Looks like they wanted to keep the interface the same for both x86-64
and 32-bit x86 so they split the offset argument in to two values.
Weirdly enough, even though these are 32-bit offsets on 32-bit x86; On
x86-64 these are still 64-bit. Which means the kernel weirdly allows you
to overlap the two 64-bit halves.
eg: `uint64_t Offset = (pos_high << 32) | pos_low;`
So you can have a 64-bit value that is the full range, but if you have
data in the lower 32-bits of pos_high then you corrupt the offset.
Additionally this allows you to interleave low and high if you want to
be obtuse.
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
A bunch of these were defined incorrectly. I tested a few of these
locally to ensure they were correct after the fact.
Shows that most 32-bit applications that we've encountered aren't
dealing with files larger than 4GB.
These 32bit syscalls use a compat statfs which is only 64bytes in size.
This was overwriting data on the guest stack and causing crashes.
Describe a 32-bit statfs struct and ensure with struct verifier that it matches.
Fixes a crash in KOTOR2 that would happen just before the main menu.
FD flag remapping was broken. It would remap one flag on to another and then the next check would remap it back.
Instead keep a mask of the flags to be remapped then remap them all at the end.
Also goes through the ops and fixes a few cases where it was remapping wrong flags.
The vast majoirty of syscalls don't need anything in thread or frame.
So lets save an indirection for all those syscalls.
Most of the syscalls which do need Thread (or CTX via
Thread are in Thread.cpp or Memory.cpp
These have all been modifiy to fetch Thread from Frame
Sadly these things can't be split without breaking functionality so it
turns in to a bit of a mess.
SyscallHandler is very much something that is a Linux only construct and
shouldn't be in FEXCore itself. Lets the frontend register a
Syscallhandler with FEXCore. FEXCore itself is then aware of the current
syscall ABI and handles the ABI in an optimal fashion.
So it is not a 100% clean break otherwise we would lose performance.
The SignalDelegator then needs to move to the frontend since the
SyscallHandler requires it for signal based syscalls.
The CPU backend signal handling still needs to happen in FEXCore because
it is a very tight coupling with the CPU backend.
Once we need to support more Signal handling we can give the backends
cleaner support to select which specific OS handler to handle.
Ryan Houdek