In the case of a kernel older than 4.17 then MAP_FIXED_NOREPLACE doesn't exist.
This adds a check in to see if the pointer returned was valid but not what we asked for
Instead of forcing a fixed offset for the stack. Allow it to get placed automatically.
64-bit was already doing this; Now we can also do it in 32-bit.
This is possible because the mapper that is mapping the code will always map in the 32-bit space
for a 32-bit guest.
This function does everything required for setting up a squashfs as a rootfs.
- Checks if the file is a valid squashfs
- Executes the FEXMountDaemon
- Error checks to ensure it was mounted correctly
- Updates CONFIG_ROOTFS to point to the mounted location
- Takes 200-400ms more startup time
This is a tool that communicates with FEXLoader/FEXInterpreter to automatically mount
squashfs based rootfs files on execve.
This tool will launch automatically if you have a squashfs based rootfs selected.
Once the rootfs is mounted, it will watch for the parent FEX processe to completely exit.
Once the parent FEX exits it will unmount and cleanup after itself.
This tool has a dependency on your host having FUSE, fusermount, and squashfuse applications.
If anything goes wrong in the bringup process then it propagates the erro up the chain and will
let FEX know that it couldn't mount.
We already have a Config.h which conflicts with this file.
In issue cropped up if you need to include Config.h (the generated one)
from inside Common/ then it would only pull the Common/Config.h file.
Just change the name to not be confusing
Allows lookups with const char* and other non-allocating string types to
be performed without constructing a std::string instance.
Reduces heap usage a little.
If a 32-bit application leaves a temporary file dangling from one of the EmulatedFiles
then glibc tries to clean up the FILE object on shutdown.
This results in a crash on 32-bit applications because our memory allocator will have already cleaned up
at that point
Use raw FDs in this instance which matches better with the syscall hooking expecting raw FDs anyway.
Due to our current allocation strategy. This variable was ending up in a weird state
where jemalloc allocated it using the glibc allocator.
On shutdown this was causing it to try and deallocate through FEX's allocator...Which
is very broken.
This lets linux clean up in this case, at least until the allocator lines are more
strongly written
std::unexpected was deprecated in C++11 and removed from the standard in
C++17. The default unexpected_handler calls std::terminate, so this is
identical behavior.
This class is partially allocated on either side of the allocator fence.
Moves `Sections` over to a unique_ptr so we can clear this variable prior to shutdown.
The rest of the class is allocated prior to switching to FEX allocator
The syscall is defined as taking in an array, so we can construct the
std::vector in place and surround it.
This also fixes an edge case where an out of bounds access on the
Host_iovec vectors could occur if these syscalls were called with an
iovcnt of zero (.at would cause an exception to be thrown).
Looking into the syscalls for readv and writev, these just return early
if a size of zero is passed in.
Similarly to #1064, an application could potentially pass in bad values
that could result in assertions/exceptions being thrown, so we can
guard against that.
Despite the manual saying that applications *must* not pass
maxevents less than or equal to zero, against all odds, this is
still a handled case in the kernel, so some application out there
may rely on this behavior.
Similarly to #1064, an application could potentially pass in bad values
that could result in assertions/exceptions being thrown, so we can guard
against that.
Despite the manual saying that applications *must* not pass maxevents
less than or equal to zero, against all odds, this is still a handled
case in the kernel, so some application out there may rely on this behavior.
std::unexpected() was deprecated in C++11 and removed from the standard
in C++17. The default unexpected_handler would call std::terminate
anyway, and given we don't explicitly set a termination handler (as far
as I can tell), this retains identical behavior.
std::function is allowed to allocate if the size of captures exceeds its
internal storage buffer. It's unlikely this is regularly going to be the
case, but we can allow for avoiding it where necessary.
Allows for better detection of out of bounds accesses, as library
implementations generally allow conditional enabling of bounds checks
through preprocessor defines.
Ryan Houdek