static-pie is crashing early due to an issue with pthread symbols being exposed as weak.
For some reason the weak symbols never get resolved and jump to zero or ELF base.
When linking static-pie, force search for the pthread symbols using an undefined glob.
With this, static-pie works as long as you link with a new enough version of lld (version 13.0)
This option does cmake checks to determine if your system can handle static-pie.
With upstream projects static-pie only works if you use the binutils linker.
Using lld doesn't currently work because it defines __rela_iplt_{start,end} symbols.
Our cmake file will now compile a test application and check for these symbols.
Either the symbols will not exist at all or they will exist but be a null address
Once your system passes the checks then it will allow you to enable static-pie
This doesn't currently install thunks which can come a bit later.
We require a postinst and prerm step for importing and unimporting the binfmt_misc files.
Easy enough
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
Begins the process of addressing issue #146.
This is separated off, so that others can make use of fmt for other
purposes (general localized non-sucky string formatting), while the
logging rework is being tackled.
xxhash doesn't yet have a version of the library with pkg-config giving
a version.
Debian has backported a change for this but Arch hasn't.
https://github.com/Cyan4973/xxHash/issues/524
This is necessary for building FEX packages that contain some initial thunk libs.
Gives an initial foothold for a default location for the host and guest thunk folders
This way we don't need to redeclare the arguments twice
Also moves IWYU lower so it doesn't hit any external projects other than FEXCore
Still not running these since everything needs to be cleaned up anyway
Lets users know that x86-64 isn't our optimal target but can still be used if passed in a new cmake argument.
Easy enough just pass in -DENABLE_X86_HOST_DEBUG=True to cmake.
Closes#776
Some of the newer CPU cores in LLVM's source claim to be a Cortex-A73,
which means they become limited to an ARMv8.0 feature set.
This is what you get if you compile FEX with -mcpu=native
To work around this issue, manually parse /proc/cpuinfo ourselves and
pull out the CPU type to pass to clang directly.
This also fixes the issue that we were using -march on AArch64, which no
longer works on newer clang versions. We instead need to use mcpu or
mtune.
Should improve all atomic op performance outside of the JITs, where they
were turning in to loadstore exclusive pairs.
There are a few nice features in C++20 that can make our life easier.
This isn't requiring the full C++20 suite of features, but instead
should allow us to start bringing in features that were at least in
Clang 10.
LLVM 11 came out yesterday (2020-10-12) so it would be a shame to have
that as a minimum requirement.
