Configuration mapping was duplicated between three different tables.
Additionally default configuration values were strewn about. Making it confusing as to what the default value would end up being
Adds a new ConfigValues.inl header that defines a few things right next to each other.
Defines the enum name as usual.
Defines the JSON config option name.
Defines the Environment config option name
Defines the default value that the configuration should be
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.
If we want to execve files directly we need to ensure that the
binfmt_misc interpreter path is installed.
If it isn't installed then we need to fall down the regular path of
pushing FEX to the front of the argument list.
fstatfs64 and statfs64 was wrong, the syscall doesn't quite match the
glibc definition
Fixes recvmsg. Specifically the aux data was failing, thus SCM_RIGHTS
wasn't getting passed correctly.
Fixes a couple of time syscalls where their arguments are optional.
This implements a bunch of new 32bit syscalls which almost gets FEX to
be able to run Steam.
The main missing syscalls are mremap, shmat, and ioctl for supporting
Steam execution.
This removes the bad attempt to keep shm regions in our 64GB shm region
This will need to be handled specially on the 32bit side through its
memory management once we have that wired up
This doesn't change behaviour on the 64bit side of things.
Currently the 32bit syscall implementation is "best effort".
Anything that easily maps is passed through, and a few minor ones that
rely on iovec are handled.
Still around 80 syscalls that aren't punched through yet.
Few of these changes could have been split up so it's a bit of a
nightmare.
Almost all of these end up being simple passthrough.
This covers most syscalls, the remaining ones are signal related, exec
related, or rseq required.
All of these syscalls exist prior to Linux 5.0. We are using these with
the expectation still that the host Linux implementation is 5.0 or
higher.
Once we implement newer syscalls we will need to start checking for host
Linux version. We don't really have a care about devices shipping older
4.x kernels atm.
This helps out Mono's garbage collector specifically. There is a minor
race that can currently occur with signal 63 but that technically should
only occur on a pause or stop condition.
Might need to change this behaviour if it becomes a problem
Since we track the PID and TID of the threads for signaling purposes, we
had the problem that if a process forked and the child then shuts down.
It was still tracking the parent thread as executing, thus it would send
it a tgkill to shut it down.
This was unintended behaviour and is now stopped
Just use the syscall directly rather than call through the glibc
interface.
The getpriority syscall biases the return value so it never returns a
negative, while the glibc interface returns [-20,19), so you need to do
some errno juggling for the -1 return.
Just use the syscall directly instead
Fixes some game complaining heavily when getpriority results were wrong
Instead of having this file mostly just copy and pasted, it'll now be
generated.
We end up losing a lot of supported flags with this change, which is for
the best since we wouldn't have actually supported those things.
This requires implementing custom ASM dispatchers for the interpreter
side of things so it works correctly.
Allows all of our CPU backends to safely support signaling.
This is a bit of a nightmare change and requires rethinking logic about
debugging in some instances.
Any time a guest signal is blocked, add it to the guest signal mask.
This doesn't use a signal queue so repeat signals can end up being lost.
This is expected behaviour
This doesn't help with implementing the problem of unblocking signals
causing the masked signal to be resent
This syscall requires the application to have root and will fail with
-EPERM otherwise.
Implementing this as just an -EPERM return allows Crispy Doom to run
It needs to track guest SigAltAction and have its own definitions for
sigaction and sa_mask. sa_mask specifically is defined differently
between the kernel and glibc.
Also fixes some issues with the SignalDelegator that posix tests found
Stefanos Kornilios Mitsis Poiitidis