If the guest application tried pushing arguments then optparse was still
capturing them as unknown and failing.
Just push the arguments directly in to our argument lists
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.
- InvalidateFlags pseudo-op is a hint for the Dead Flags Elimination pass that flags are not needed past that point
- Adds a new option, --abi-local-flags, that invalidates the flags on CALLs or RETs. This might break code that doesn't follow the ABI rules.
This dumps the IR before and after optimizations
--dump-ir can be
"no" -> Do not dump
"stderr" -> Dump to stderr
"stdout" -> Dump to stdout
"some/path" -> Dump to "some/path/$GuestRip-pre.ir" and "some/path/$GuestRip-post.ir"
Just ensures that it gets stored in the correct XDG or ~/ config
directories.
If these don't exist then it'll get dumped in to PWD or cwdir, whichever
is available as fallback
This is just a virtual number that the guest can query through the
various means. Will affect mesa with how many helper threads it
generates at the very least
In the case of multiple dozens of tests running, they will end up
loading and saving the config files dozens of times.
This was causing the configuration system to load in half saved files
that were causing common crashes in the posix unit tests.
Theoretically this could have happened at any time but it looks like
with the posix unit tests added, it is just more likely to happen.
Makes it so loading the configuration file is much more robust and
verbose on failure.
Makes it so saving the config file first saves to a temporary and then
moves in to the correct location. This causes the config saving to be
atomic in a sense so the unit tests won't corrupt other processes of FEX
trying to load the config file.
Stefanos Kornilios Mitsis Poiitidis