This was a missing feature that I had skipped previously.
Before this commit, each layer would overwrite all previous environment variables if they had anything defined.
After this commit, the layers will now merge in priority order.
Meaning if a higher priority layer has the same environment variable defined, it will overwrite that specific variable
Ending up with a superset of all the layer's environment variables now.
Useful for debugging but we need to be silent by default now.
Without this anything that checks stdout output of applications from bash would fail
Steam with lspci, lsusb, uname, etc
This was previously just some default values that I put in as placeholder
Now that we actually have defaults configured somewhere, use those.
Fixed#874
This has the expected behaviour that the configuration option will be available and not default initialized.
To enforce this fact, it will assert if it tries to get a value that doesn't exist yet.
Passes the result back up to the frontend as well which allows us to early exit correctly.
Also ensures that we return ENOEXEC on these error cases so if someone is waiting on a return value, they don't just get zero
Fixes#757
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
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
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.
