Base size is now only one page in size. We will then increment that BRK
size by 8MB alignments. 256MB for 32bit applications was causing some
applications on the edge to run out of virtual memory
I was hitting some 32bit applications that were being fairly mean with
BRK. They were allocating all of BRK space then running out of virtual
memory space with its mmap handler fallback after freeing BRK space.
This means we now munmap BRK pages on release for the guest, similar to
behaviour that Linux does.
Additionally I had an application that was getting very upset that BRK
wasn't actually at the end of program space. So allocate at the end of
program space like expected.
brk test now passes from gvisor
This is what shows up in /proc/cpuinfo
example on tagged release: 'model name : FEX-2101'
example on untagged release: 'model name : FEX-2101-64-g536be23f'
Fixes#661
In the case of an instruction that used 16bit addressing mode. It would
calculate the amount of displacement needing to be read using a 32bit
modrm mode. It would then read calculate modrm displacement again and
read the correct number of bytes.
Leftover bytes would then be in a mismatched state which means if an
instruction was using 16bit addressing + modrm + literal at /that/ point
the number of literal bytes remaining would be calculated as a negative.
This didn't actually break things since instructions that have modrm +
literal and can safely use 16bit addressing without breaking in a 32bit
environment is impossible on Linux. Due to the inability to map a memory
range in 16bit range.
Instead of hardcoding 64bit dynamic ELF files to 0x1'0000'0000 we
instead calculate the size of the ELF in memory. Then allocate the
ELF base up front.
LLVM ASAN steals a large amount of virtual memory space that intersected
with the original hardcoded range which caused memory allocations to
fail.
Patch moves HandleSIGSEGV in HostFactory.cpp to a non-frontend host signal handler, then registers its own frontend signal handler to catch unhandled segfaults.
Both x86 and AArch64 support converting from one sized GPR to another
sized FPR. Expose it in our IR op.
Fixes a bug in CVTSI2SS with a 64bit source and it was treating the
input source as a 32bit value.
eg:
0x0000'0000'FFFF'FFFF was treated as converting to -1 float, which was wrong since it is a 64bit value
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.
Instead of having the configuration being loaded and stored in to a
frontend system. First moves the backing store of the configuration in
to FEXCore.
Each layer that is constructed then loads its particular configuration.
After the layers are loaded, then a meta layer is constructed that
merges the layers flat.
This means we will no longer hit the problem where a configuration is
stored in the "main" configuration file, then environment and arguments
passed manage to overwrite it.
The order of the layers going from inner most layer to outer most, with
outermost overwriting previous layer configurations is as follows:
Main < Global application < Local application < Arguments < Environment
One step that needs to be changed in the future is that FEXCore can then
just load its configuration from the layers directly since the data is
in FEXCore now. This will be reserved for a future change so we are less
disruptive.
