Previously this would result in a larger amount of words specified than
necessary.
e.g. Given nfds = 1:
With AlignUp(1, 32) / 4, we'd end up with supposedly eight words, when it
should only be one word.
On the other extreme, given a full fd set of 1024 fds, then we'd end up
with 256 words, when it should only be 32.
CopyToUser doesn't return the number of bytes copied, but rather returns
0 to indicate success, otherwise a fault has occurred (and the SIGSEGV
handler has set X0 to EFAULT)
building using musl fails due to missing defintions:
```
Source/Tools/LinuxEmulation/LinuxSyscalls/Syscalls.cpp:913:23: error: no member named 'sleep_for' in namespace 'std::this_thread'
913 | std::this_thread::sleep_for(std::chrono::milliseconds {10});
| ^~~~~~~~~
1 error generated.
```
Signed-off-by: Pepper Gray <hello@peppergray.xyz>
musl build fails due to access to internal glibc member:
```
FEX/Source/Tools/LinuxEmulation/LinuxSyscalls/SignalDelegator.cpp:655:39: error: no member named '__val' in '__sigset_t'
655 | .SigMask = _context->uc_sigmask.__val[0],
| ~~~~~~~~~~~~~~~~~~~~ ^
1 error generated.
```
add check to determine private glibc or musl member name or throw an error.
fixes: #5461
Signed-off-by: Pepper Gray <hello@peppergray.xyz>
building on clang/musl fails with:
```
FEX/Source/Tools/LinuxEmulation/LinuxSyscalls/GdbServer.cpp:1174:5: error: use of undeclared identifier 'tgkill'
1174 | tgkill(::getpid(), ::getpid(), SIGKILL);
| ^~~~~~
1 error generated.
```
include and use `FHU::Syscalls::tgkill`.
fixes: #5463
Signed-off-by: Pepper Gray <hello@peppergray.xyz>
The previous `ForkableSharedMutex` using `std::shared_mutex` was showing
up as significant CPU time on arm64ec. In particular it was showing up
upwards of 700ms/S of CPU time for read-contented workloads at only
~2700 locks per second. The libc++ implementation for arm64ec must be
particularly gnarly for this to be so slow.
With this swapped over, it's now only spending around 56ms/S on the
contended shared lock, but at ~8000 locks per second. So a significant
uplift.
This was causing an unfortunate set of circumstances where Dark Souls
III was modifying MXCSR and we weren't saving it, cause the value to change
from 0x9fc0 to 0.
This "enabled" float exceptions by unmasking the exception masks in
MXCSR. This in turn had Dark Souls III's `expf` function to fault out,
as it checks if the MXCSR exception masks are set or not for determining
if underflow should assert or not.
Wow64/arm64ec has a similar problem where it always sets back to default
on signal. Which means game lose DAZ, but I'm not fixing that bug right
now.
Fixes#5391
Ryan Houdek