Keeping this in the commit history to go back to later.
While these are required for static-pie builds to work, with the glibc
bug we can't use those yet.
Disable for now since it is is unnecessary.
If the thunk configuration is enabled then preemptively load the
libraries. Since they will need to be loaded for any thunking library.
This is because we need to ALWAYS share the allocators to the thunks.
This is specifically the device loader rather than the libvulkan loader
library.
This is meant to override what is provided in the ICD files, not the
loader.
There's no real need to replace the loader, it's quite complex
These are required to expose FEX's allocators to the guest.
Which is required when we are compiled with jemalloc, otherwise
the libraries will crash on allocations.
This needs to be done in stages otherwise glibc will load the library
and as it is setting up symbols, replace malloc, which isn't set
currently and cause a crash
This adds a new `ThunksDB.json` file to the config folder.
This file lets users describe thunks in a meaningful way without
duplicating it amongst multiple configuration files.
eg:
```
{
"DB": {
"GL": {
"Library" : "libGL-guest.so",
"Depends": [
"X11"
],
"Overlay": [
"/usr/lib/x86_64-linux-gnu/libGL.so",
"/usr/lib/x86_64-linux-gnu/libGL.so.1",
"/usr/lib/x86_64-linux-gnu/libGL.so.1.2.0",
"/usr/lib/x86_64-linux-gnu/libGL.so.1.7.0",
"/lib/x86_64-linux-gnu/libGL.so",
"/lib/x86_64-linux-gnu/libGL.so.1",
"/lib/x86_64-linux-gnu/libGL.so.1.2.0",
"/lib/x86_64-linux-gnu/libGL.so.1.7.0"
]
},
"X11": {
"Library": "libX11-guest.so",
"Overlay": [
"/usr/lib/x86_64-linux-gnu/libX11.so.6",
"/lib/x86_64-linux-gnu/libX11.so.6"
]
}
}
}
```
This file lets the user describe the library with an nicer name, in this instance
`GL` instead of `libGL-guest.so`.
It also tracks depedencies, like how GL currently has a hard dependency on X11.
This allows the loader to automatically enable the dependencies if described.
The `Overlays` array is like the regular Thunks config file but now in this DB file.
With the DB file now describing the libraries, this allows us to then stick a lighter
description inside of the Thunk Config file.
```
{
"ThunksDB": {
"GL": 1
}
}
```
With this example Thunk config file (Which can be configured per application), There is
a new property of name `ThunksDB`.
All this takes is key:value pairs which describe the user friendly library name and an Integer
to state if the thunk should be enabled or not.
This allows very quick toggling of thunks directly inside of the configuration files rather than
breaking the configuration to disable it.
Allows having a library filename be different from the name.
This will fix a quirk in future thunks where the library name and
filename don't match
Also allow custom callback unpacks. A future thunk will need this
Instead of searching inside the thunk folder for Guest and Host files
with a library name attached to it, also search for ones That are just
named `Host.cpp` and `Guest.cpp`.
Makes quickly pounding out a bunch of thunks significantly less tedious.
Makes it print to stderr instead of stdout.
Also sets the mutex symbols to something that can be debugged.
Found something linking to them but not actually using them.
This is very useful for extracting function definitions for thunks.
Keep it in upstream to not get lost.
Sometimes it can munge a definition but it is usually fine.
These are pulled from headers using an automated script.
Almost all functions are easy drop in, only a handful are commented out.
Works in every game that I've tested.
There was a hard upper limit to 128 json elements, this has now been
removed.
The debugging text for the thunk overlay is now disabled. It can get
very spammy but it is useful for debugging purposes.
Fixes an issue where thunks would be entirely disabled if a RootFS isn't
set.
This meant debugging in a chroot or x86_64 host was breaking rootfs
epoll_pwait has a sigsetsize argument, which was unused in this case but
it caused strace to look ugly.
On epoll_ctl, don't write back the resulting event. The event isn't
written and depending on how the guest allocated the object, we could
have a 4byte overwrite.
Ryan Houdek