diff options
Diffstat (limited to '')
31 files changed, 415 insertions, 0 deletions
diff --git a/results/scraper/fex/12 b/results/scraper/fex/12 new file mode 100644 index 000000000..b22e1a84b --- /dev/null +++ b/results/scraper/fex/12 @@ -0,0 +1,7 @@ +Syscall emulation has incorrect global mutex +There is a scoped mutex at the top of the syscall handling function. +This is incorrect and causes the application to stall once threading kicks in. +Should be removed and only have a mutex on things that actually need it. +Can be done alongside syscall cleanup. + +I think skmp wanted to have a go at this? \ No newline at end of file diff --git a/results/scraper/fex/1200 b/results/scraper/fex/1200 new file mode 100644 index 000000000..e645c0e43 --- /dev/null +++ b/results/scraper/fex/1200 @@ -0,0 +1,3 @@ +Remove static initializers that allocate memory +Any sort of static initializer that allocates memory and registers an atexit handler is prone to crashing when running in a 32-bit environment. +We need to remove all of these from our codebase. \ No newline at end of file diff --git a/results/scraper/fex/1203 b/results/scraper/fex/1203 new file mode 100644 index 000000000..609e72c08 --- /dev/null +++ b/results/scraper/fex/1203 @@ -0,0 +1,56 @@ +Support thunking of vtables and function pointer members +Many APIs return objects with function pointer data members (e.g. vtables). These are difficult to handle, since both the host libraries (invoked through thunklibs) and the guest program expect to be able to call them. FEX's existing callback mechanism isn't suitable for this. + +I've researched other strategies to handle this scenario, the most universal one being Option 3 below. The other options are included for reference, since their drawbacks highlight why option 3 is needed for the general case. + +*For illustration, consider this example guest API: `Object* CreateObject()` and `struct Object { void (*funcptr)(Object*); }`.* + +## Approach 1: Guest-side mirror copy + +In addition to the hostlib-created object, a mirror copy is created where all function pointers are replaced with guest-function pointers. The two are stored in a wrapper struct `struct Wrapped { Object guest_obj; Object* host_obj; }`, which can be cast to/from the `Object` pointer as seen by the guest. + +This requires synchronizing the two copies at each guest<->host transition point. For guest->host, data (excluding function pointers) from `guest_obj` must be copied to `*host_obj`, and vice-versa for host->guest. + +👎 Overhead due to object copying +👎 Only works for function pointers that take a `this` argument (otherwise, there's no way to look up `host_obj`) +👎 Requires lots of boilerplate +👎 Does not work for APIs where the guest is in charge of destroying the object using external functions (e.g. free() instead of XDestroyImage). More generally it doesn't work for libraries that have any dependency on the object address whatsoever. +👎 Unreliable if the host may modify Object data outside of API calls (e.g. for async code) +👎 Further workarounds required if the guest overwrites function pointers + +## Approach 2: `Object*->host_vtable` dictionary + +CreateObject in Host-thunklib replaces the vtable of the created object with guest function pointers but stores the old one in an `std::unordered_map` for future lookup. + +This approach requires the vtable in the object to be swapped for each host<->guest transition, but compared to approach 1 this is cheaper and requires less boilerplate. + +👎 Only works for function pointers that take a `this` argument (otherwise, there's no way to look up `host_vtable`) +👎 Space overhead due to the (possibly large) dictionary +👎 Small performance overhead due to dictionary lookup +👎 Requires some boilerplate +👎 Further workarounds required if the guest overwrites function pointers + +## Approach 3: Making selected host addresses callable from guest + +Host-thunklib forwards the unmodified object as created by the hostlib, including host function pointers. The host function pointers are made guest-callable by instructing FEX's JIT insert a trampoline in the block cache at the function pointer address. This trampoline initiates a guest->host transition to call the host function pointer. (This is possible since no guest code could've possibly been loaded at the host function pointer address anyway.) + +👍 Works for virtually all cases (no need for `this` args) +👍 No boilerplate (trampoline code is always the same) +👍 No overhead +👎 Further workarounds required if the guest overwrites function pointers +👎 Complexity + +## Approach 4: Trampolines that are valid x86 and ARM64 code + +*Okay, we're entering pretty ridiculous territory here, but for the sake of completeness if we wanted to have something like approach 3 but couldn't involve the JIT:* + +Host-thunklib forwards the unmodified object as created by the hostlib, including host function pointers. The guest-thunklib wraps each of these function pointers in a trampoline that performs a guest->host transition and then jumps to the original function pointer. + +The twist is: These trampolines are carefully written in x86 assembly code such that they [also make for valid ARM64 code](https://github.com/ixty/xarch_shellcode/tree/master/stage0). When interpreted as ARM64 code, the first instruction would be a branch to ARM64-exclusive code, skipping past the x86 payload and instead invoking the original host function pointer. + +👎 No idea if this could reasonably be made working +👍 This is a hilariously evil hack that would be so cool to see working + +## Unsolved problems: + +All approaches listed above fall apart if the guest program *overwrites* function pointers. However, in practice that's unlikely to be a problem: After all, few (no?) applications would create an object through a library and then override its vtable. diff --git a/results/scraper/fex/1206 b/results/scraper/fex/1206 new file mode 100644 index 000000000..b56ced143 --- /dev/null +++ b/results/scraper/fex/1206 @@ -0,0 +1,2 @@ +Compatible with Linux4Tegra (e.g. Nintendo Switch, Nvidia Shield)? +Asking as this would effectively solve the issue of Steam Remote Play being nearly impossible to get working adequately on the Switch with rail-based joycons (since there isn't a native version of Steam Link for ARM Linux, and Android still has incredibly buggy rail joycon support that stops working half the time). \ No newline at end of file diff --git a/results/scraper/fex/1207 b/results/scraper/fex/1207 new file mode 100644 index 000000000..a752781e9 --- /dev/null +++ b/results/scraper/fex/1207 @@ -0,0 +1,2 @@ +Add stack guards on both ends of the thread stacks +Currently we don't make stack guards. We should do that. \ No newline at end of file diff --git a/results/scraper/fex/1208 b/results/scraper/fex/1208 new file mode 100644 index 000000000..4581f153e --- /dev/null +++ b/results/scraper/fex/1208 @@ -0,0 +1,23 @@ +Reasons to fork glibc +We really don't want to do this, but there are some reasons to go about doing this and we need to track the pain points. +This list will grow as we care about more things + +- clone support + - There are a lot of clone flags that can't be accurately wrapped while using glibc + - One of the big issues is that a guest application can be using clone directly, with flags that if we allow it breaks FEX's TLS usage. + - This is because glibc doesn't provide us a way to do clone flags plus keeping our TLS setup working + - We would need to fork glibc to expose a subset of flags AND keep our TLS working. +- 32-bit thunks + - In order to keep 32-bit VA usage down, we will need to wrap the mmap and munmap usage inside of glibc's dynamic loader + - The 32-bit side of the thunk stays in the 32-bit VA space. + - A significant amount of the 64-bit side could live in 64-bit VA space + - Exported symbols would need to still live in the 32-bit VA, which means the full host library also needs to live in the 32-bit VA, or we need to duplicate the symbol inside of the 32-bit space + +- Guest thunk hooks + - Add support for hooking when symbols are loaded so we can partially thunk a library + - A bit gross but would work for partial thunking? + +- Guest thunk callback support + - If the thunk creates a thread and is expected to call in to the guest as a callback. Then TLS state doesn't exist + - We could have a TLS region allocated for a guest thread post-thread creation if this was the case + - Bit of a faff \ No newline at end of file diff --git a/results/scraper/fex/1212 b/results/scraper/fex/1212 new file mode 100644 index 000000000..f09417962 --- /dev/null +++ b/results/scraper/fex/1212 @@ -0,0 +1,28 @@ +Build it on termux? +Can i build the emulator on termux? +``` +~/FEX/build $ sudo ninja install +[0/2] Re-checking globbed directories... +[10/283] Building C object External/jemall...akeFiles/FEX_jemalloc.dir/src/jemalloc.c.o +FAILED: External/jemalloc/CMakeFiles/FEX_jemalloc.dir/src/jemalloc.c.o +/data/data/com.termux/files/usr/bin/clang -DENABLE_JEMALLOC=1 -DGLOBAL_DATA_DIRECTORY=\"/usr/share/fex-emu/\" -D_GNU_SOURCE -D_M_ARM_64=1 -D_REENTRANT -I/data/data/com.termux/files/home/FEX/build/External/jemalloc -I/data/data/com.termux/files/home/FEX/External/jemalloc -I/data/data/com.termux/files/home/FEX/External/vixl/src -I/data/data/com.termux/files/home/FEX/External/xxhash -I/data/data/com.termux/files/home/FEX/External/jemalloc/pregen/include -I/data/data/com.termux/files/home/FEX/External/jemalloc/include -O3 -DNDEBUG -flto=thin -fPIC -Wno-trigraphs -fvisibility=hidden -std=gnu11 -MD -MT External/jemalloc/CMakeFiles/FEX_jemalloc.dir/src/jemalloc.c.o -MF External/jemalloc/CMakeFiles/FEX_jemalloc.dir/src/jemalloc.c.o.d -o External/jemalloc/CMakeFiles/FEX_jemalloc.dir/src/jemalloc.c.o -c /data/data/com.termux/files/home/FEX/External/jemalloc/src/jemalloc.c +/data/data/com.termux/files/home/FEX/External/jemalloc/src/jemalloc.c:714:9: error: use of undeclared identifier 'secure_getenv' + return secure_getenv(name); + ^ +/data/data/com.termux/files/home/FEX/External/jemalloc/include/jemalloc/internal/test_hooks.h:15:37: note: expanded from macro 'secure_getenv' +#define secure_getenv JEMALLOC_HOOK(secure_getenv, test_hooks_libc_hook) + ^ +/data/data/com.termux/files/home/FEX/External/jemalloc/src/jemalloc.c:744:3: warning: implicit declaration of function 'pthread_getaffinity_np' is invalid in C99 [-Wimplicit-function-declaration] + pthread_getaffinity_np(pthread_self(), sizeof(set), &set); + ^ +/data/data/com.termux/files/home/FEX/External/jemalloc/src/jemalloc.c:3020:24: error: conflicting types for 'malloc_usable_size' +JEMALLOC_EXPORT size_t malloc_usable_size(void *ptr) { + ^ +/data/data/com.termux/files/usr/include/malloc.h:104:8: note: previous declaration is here +size_t malloc_usable_size(const void* __ptr) __INTRODUCED_IN(17); + ^ +1 warning and 2 errors generated. +[19/283] Building C object External/jemalloc/CMakeFiles/FEX_jemalloc.dir/src/ctl.c.o +ninja: build stopped: subcommand failed. +~/FEX/build $ +``` \ No newline at end of file diff --git a/results/scraper/fex/1213 b/results/scraper/fex/1213 new file mode 100644 index 000000000..5e450838d --- /dev/null +++ b/results/scraper/fex/1213 @@ -0,0 +1,4 @@ +Proton 6.3 hangs when run from Steam +When running Proton 6.3 built from source then games run fine. +When run inside of the pressure-vessel runtime with the official distributed version then it hangs for some reason. +Need to investigate and diagnose why this is. Otherwise we are stuck with Proton 5.13 testing. \ No newline at end of file diff --git a/results/scraper/fex/1214 b/results/scraper/fex/1214 new file mode 100644 index 000000000..c13fb50f3 --- /dev/null +++ b/results/scraper/fex/1214 @@ -0,0 +1,4 @@ +Serious Sam: The First Encounter crashes early in engine code +https://www.gog.com/game/serious_sam_the_first_encounter +https://store.steampowered.com/app/41050/Serious_Sam_Classic_The_First_Encounter/ <- Untested but might be the same release. +When run under Wine 6.15 the game crashes fairly early in its engine code when it is trying to read some sort of string. It reads 0x20000 bytes of something and overwrites to the next page which faults. \ No newline at end of file diff --git a/results/scraper/fex/1217 b/results/scraper/fex/1217 new file mode 100644 index 000000000..94b9f97dc --- /dev/null +++ b/results/scraper/fex/1217 @@ -0,0 +1,19 @@ +Support SIGILL to the guest +Currently FEX will just close an application if it encounters a block with an invalid instruction. +We can support giving the guest a SIGILL. +This should be done in two steps to reduce the amount of immediate work + +1) Support the use-case of SIGILL + guest handler terminate + - This means that once the frontend encounters and invalid operation. + - Save Thread state + - End the Block + - Call a SIGILL host side handler + - Pass the signal information to the guest + - Invoke the guests signal handler with the known good information + - Guest will invoke terminate, thus taking down the application and FEX with it + 2) Once step 1 is done, support use cases where an application is testing for instructions and safely recovering + - Guest will modify the passed in ucontext once it has caught the sigill + - Most likely modifying RIP to jump past the instruction, or using longjump to escape + - Will likely also modify another GPR to know the failure case + - Once the guest has returned from its signal, we need to read the state back in to our context and safely continue + - This can benefit more than SIGILL later once we have some form of state recovery for the other signals. \ No newline at end of file diff --git a/results/scraper/fex/1220 b/results/scraper/fex/1220 new file mode 100644 index 000000000..ab8778d0a --- /dev/null +++ b/results/scraper/fex/1220 @@ -0,0 +1,6 @@ +32-bit Source games can't rotate camera 360 degrees +32-bit source games have a quirk where you can't rotate the mouse 360 degrees in both directions. +Moving right to left it is fine. +Moving left to right then the rotation will stop at some consistent point. + +This is either a math bug in the CPU emulation or an ioctl bug in our ioctl emulation. \ No newline at end of file diff --git a/results/scraper/fex/1221 b/results/scraper/fex/1221 new file mode 100644 index 000000000..932d97a99 --- /dev/null +++ b/results/scraper/fex/1221 @@ -0,0 +1,2 @@ +Throw an error when compiling and running on a non-4k page host +Completely untested, expected to break spectacularly. Don't try it. \ No newline at end of file diff --git a/results/scraper/fex/1228 b/results/scraper/fex/1228 new file mode 100644 index 000000000..384f85b93 --- /dev/null +++ b/results/scraper/fex/1228 @@ -0,0 +1,7 @@ +Guest signal handling should be setup to use rt_sigreturn +Currently we setup using a unique instruction for returning from a guest signal handler. +We should instead use the "correct" setup of using the handler restorer. +This will grant us support for guest applications using the restorer and we can drop usage of a custom instruction here. + +With the movement of the guest signal frame moving from FEXCore to FEXLoader, this will become easier to support. +Since the signal frame setup needs to be understood on both sides. \ No newline at end of file diff --git a/results/scraper/fex/1241 b/results/scraper/fex/1241 new file mode 100644 index 000000000..e25d33887 --- /dev/null +++ b/results/scraper/fex/1241 @@ -0,0 +1,4 @@ +Support 64-bit ioctl emulation +Thunks will largely take care of this but for the fallback case we need to support emulation to work around struct packing quirks. +This mainly comes from 64bit values having a 4 byte alignment on x86 and x86-64 while on aarch64 they have natural alignment. +I have already encountered this issue on V3D/VC4 ioctls. \ No newline at end of file diff --git a/results/scraper/fex/1245 b/results/scraper/fex/1245 new file mode 100644 index 000000000..80a4516d7 --- /dev/null +++ b/results/scraper/fex/1245 @@ -0,0 +1,3 @@ +Support runtime selection of atomic ops on the interpreter +With #1244 merged. The Interpreter now uses only ARMv8.0 atomics for OP_CAS. +Once we switch to a dispatcher jump table like ARM and x86-64 JIT, then we should do a runtime selection for the inline ASM or std::atomic using the ARMv8.1 ops. \ No newline at end of file diff --git a/results/scraper/fex/1251 b/results/scraper/fex/1251 new file mode 100644 index 000000000..577681272 --- /dev/null +++ b/results/scraper/fex/1251 @@ -0,0 +1,2 @@ +32-bit syscalls using timex is incorrect +Struct layout is significantly different. \ No newline at end of file diff --git a/results/scraper/fex/1252 b/results/scraper/fex/1252 new file mode 100644 index 000000000..7c7c4b78c --- /dev/null +++ b/results/scraper/fex/1252 @@ -0,0 +1,2 @@ +32-bit syscalls using shmid_ds is incorrect +Struct layout is significantly different \ No newline at end of file diff --git a/results/scraper/fex/1253 b/results/scraper/fex/1253 new file mode 100644 index 000000000..d275c8f88 --- /dev/null +++ b/results/scraper/fex/1253 @@ -0,0 +1,2 @@ +32-bit syscalls using msqid_ds is incorrect +Struct layout is significantly different \ No newline at end of file diff --git a/results/scraper/fex/1254 b/results/scraper/fex/1254 new file mode 100644 index 000000000..2db518fd6 --- /dev/null +++ b/results/scraper/fex/1254 @@ -0,0 +1,2 @@ +32-bit syscalls using siginfo_t is incorrect +Struct layout is significantly different. \ No newline at end of file diff --git a/results/scraper/fex/1258 b/results/scraper/fex/1258 new file mode 100644 index 000000000..cb838d672 --- /dev/null +++ b/results/scraper/fex/1258 @@ -0,0 +1,7 @@ +Gamepad input is inconsistent? +Noticed this while running Scourgebringer (https://store.steampowered.com/app/1037020/ScourgeBringer/) +This is a native Linux 64-bit application. +Noticed while running on an AArch64 host. Haven't tested on an x86-64 host. +Could be ioctl related? + +Had a basic Xbox One controller connected over USB and the game didn't see its inputs at all. \ No newline at end of file diff --git a/results/scraper/fex/1260 b/results/scraper/fex/1260 new file mode 100644 index 000000000..632f79d55 --- /dev/null +++ b/results/scraper/fex/1260 @@ -0,0 +1,4 @@ +Syscalls using sigevent are incorrect. +Syscalls using this: mq_notify and timer_create. +Structure is a different size between 32-bit and 64-bit. +Also the signal handling behaviour isn't correct at all. \ No newline at end of file diff --git a/results/scraper/fex/1261 b/results/scraper/fex/1261 new file mode 100644 index 000000000..a3500322d --- /dev/null +++ b/results/scraper/fex/1261 @@ -0,0 +1,2 @@ +Implement BMI1 and BMI2 +These map quite well to AArch64. We should probably just support this. \ No newline at end of file diff --git a/results/scraper/fex/1263 b/results/scraper/fex/1263 new file mode 100644 index 000000000..c287366ad --- /dev/null +++ b/results/scraper/fex/1263 @@ -0,0 +1,4 @@ +Socket based logging +Allow opening a socket and sending timestamped logs +Good for multithreaded bugging problems. +Hook up to a filterable imgui interface and...Kibana? \ No newline at end of file diff --git a/results/scraper/fex/1264 b/results/scraper/fex/1264 new file mode 100644 index 000000000..c826991ff --- /dev/null +++ b/results/scraper/fex/1264 @@ -0,0 +1,9 @@ +Chromium crashing in PRoot container on Termux +Host Distro: Arch Linux ARM aarch64 +Guest RootFS: Arch Linux x86_64 + +I tried running Chromium using FEX-Emu inside a Termux PRoot container but it crashed. (my whole Termux session crashed) + +Here are the log files (with and without --no-silentlog):- +[log.txt](https://github.com/FEX-Emu/FEX/files/7143196/log.txt) +[logv.txt](https://github.com/FEX-Emu/FEX/files/7143172/logv.txt) diff --git a/results/scraper/fex/1265 b/results/scraper/fex/1265 new file mode 100644 index 000000000..5eb039d92 --- /dev/null +++ b/results/scraper/fex/1265 @@ -0,0 +1,5 @@ +Check for container-manager redirect some folders +We need to check for `/run/host/container-manager` existing and containing `pressure-vessel` +If both those are true then we need to redirect a bunch of installed folder searches from `$CMAKE_INSTALL_PREFIX` to `/run/host/$CMAKE_INSTALL/PREFIX` + +Easy enough, just need to hit all the locations that do a search. \ No newline at end of file diff --git a/results/scraper/fex/1270 b/results/scraper/fex/1270 new file mode 100644 index 000000000..c205c6c66 --- /dev/null +++ b/results/scraper/fex/1270 @@ -0,0 +1,9 @@ +jstest-gtk i386 axis bars not rendering correctly +Noticed this while testing some ioctls. +Correct (FEX + x86_64): + + +Incorrect (FEX + x86): + + +This happens with both Interpreter and JIT. Likely a CPU emulation bug. diff --git a/results/scraper/fex/1278 b/results/scraper/fex/1278 new file mode 100644 index 000000000..1a3f928e4 --- /dev/null +++ b/results/scraper/fex/1278 @@ -0,0 +1,159 @@ +Automate thunk library generation using libclang +**Draft** sketching a possible design for a libclang-based thunk library generator. + +# Terminology + +* host library: Native host library installed globally, e.g. /usr/lib/aarch64-linux-gnu/libX11.so +* guest library: Native guest library installed in the rootfs, e.g. $ROOTFS/usr/lib/x86_64-linux-gnu/libX11.so +* guest thunk library: The shim library shipped with FEX and loaded in place of the actual guest library +* host thunk library: The shim library shipped with FEX and exporting symbols linked to guest thunk functions +* guest/host thunk functions: Shim functions exported by the guest/host thunk library +* guest/host library functions: Functions exported by the guest/host library + +# Syntax + +[Example generator input](https://gist.github.com/neobrain/67f3dc9f14d3c8a8e88bae808242dcc2) + +Thunked functions are defined by defining a struct called `fex_gen_config` and specializing it for each function that should be exported from the guest/host thunk libraries. The code emitted by the thunk generator can be customized by defining certain members to the specialized structs, as outlined below. + +```cpp +template<auto> +struct fex_gen_config { + // Global per-module (or per-namespace) settings +}; + +// For each exported function: +template<> struct fex_gen_config<XCreateIC> { + // Per-function config, see below +}; +``` + +C++ namespaces can be used to group functions together with different settings specified in the non-specialized `fex_gen_config`. + +## Per-function config + +### Variadic functions + +If the member alias `uniform_va_type` of type `arg_type` is defined, a variadic guest-function of the form `ret func(other_params, ...)` will be linked to a host-function `ret func(other_params, arg_type* args, size_t num_args)`. As indicated by the name "uniform", this can only be used when the implementation treats all parameters as the same type. + +```cpp +template<> struct fex_gen_config<XCreateIC> { + using uniform_va_type = unsigned long; +}; +``` + +### Function pointer parameters ("callbacks") + +Guest function pointers can't be used as callbacks for host libraries, so it's required to specify a strategy on how to deal with this: + +* If `fex_gen_config` inherits from `callback_through_user_data<cb_idx, data_idx>`, the guest-provided callback (parameter index `cb_idx`) is replaced by a fixed host-function and the data pointer (parameter index `data_idx`) is replaced by a custom struct containing original data pointer and the original guest callback. This wrapped data will be heap-allocated and must be deallocated explicitly. + +* If `fex_gen_config` inherits from `callback_through_user_data_on_stack<cb_idx, data_idx>`, this will have the same effect as inheriting from `callback_through_user_data`, but the internal user data struct is placed on the stack so that memory doesn't need to be deallocated explicitly. This only works if the native host library doesn't use the callback after it returns from the thunked function. + +* If `fex_gen_config` inherits from `callback_stub<cb_idx>`, the guest-provided callback is replaced by a fixed host-function that will trigger a runtime error when being called. + +* If `fex_gen_config` inherits from `callback_guest<cb_idx>`, the guest-provided callback is assumed to never be called on the host-side. This is ensured by replacing the corresponding parameter in the host library function with an uncallable opaque handle type that can only be passed back to the guest thunk library. + +### Factory functions that return objects with vtables/function pointers + +Vtables and function pointers initialized by host functions (such as when constructing objects) cannot be called by the guest. If `fex_gen_config` inherits from `fixup_vtable_in_return`, FEX will generate additional code to fixup returned function pointers with function pointers that are both host-callable and guest-callable. This is done recursively for any (possibly nested) function pointer members in the returned object. + +```cpp +template<> struct fex_gen_config<XCreateImage> : fex_gen::fixup_vtable_in_return { +}; +``` + +If `fex_gen_config` inherits from `returns_guest_pointer`, FEX will *not* generate this magic and instead trust that the host endpoint of the thunk will return a pointer that can safely be used by the guest (and will never be used by the host itself). + +- [ ] TODO: If the function returns an object with vtables but this customization is not specified, should the generator fail loudly or should it assume the function did not freshly create the object? + +- [ ] TODO: Should a customization point be added for the returned function pointer? + +### Overriding host thunk function + +Host thunk functions usually just forward their arguments to host library functions. If `fex_gen_config` inherits from `custom_host_impl`, the thunk unpacker will call `fexfn_impl_FUNC` instead of the host library function. (The latter is still available through `fex_ldr` though, hence it can be used in `fexfn_impl_FUNC` if needed.) + +```cpp +template<> struct fex_gen_config<XFree> : fex_gen::custom_host_impl { +}; +``` + +### Overriding guest thunk function + +Guest thunk functions usually just pack their arguments into a struct that is passed to `fex_thunks_<lib>_<function>`. If `fex_gen_config` inherits from `custom_guest_impl`, the generator will expect the guest entrypoint to be defined manually such that functions can be customized more freely. Packing the arguments and invoking the thunk can be done explicitly by calling `fexfn_pack_<function>`. + +```cpp +template<> struct fex_gen_config<XFree> : fex_gen::custom_guest_impl { +}; +``` + +### Adding internal parameters + +Host thunk functions usually have the same signature as the guest thunk function they're linked to. If a member type alias`internal_args`, its type will be appended to the host thunk function. + +```cpp +template<> struct fex_gen_config<XInitThreads> { + using internal_args = XUnlockMutex_fn_type; +}; +``` + +- [ ] TODO: How to specify multiple parameters? Is `std::tuple` suitable or do we need a custom type list? + +### Disabling thunking locally + +Some functions (such as printf-likes) don't need thunking per se and may be simpler to implement without. If `fex_gen_config` inherits from `guest_only`, no thunks or (un-)packing functions will be generated. The guest-side entrypoint must be defined manually + +```cpp +template<> struct fex_gen_config<XFree> : fex_gen::guest_only { +}; +``` + +## Global per-module settings + +### Automatic function discovery + +Instead of manually listing functions to be exported, the generator can automatically treat all functions declared in a library's header as if they had been defined with an empty `fex_gen_config`. Functions that cannot be processed without explicit annotation will trigger an error unless an explicit `fex_gen_config` is defined for them. + +- [ ] TODO: What syntax to use for this? How can we appropriately constrain the set to avoid invalid exports? + +### Custom host function loader +Usually, the host thunk library will load any required symbols from the native host library using dlsym. Some libraries (such as libGL) requires thunking functions that aren't exported by the library directly but exposed through a dedicated lookup function (e.g. glXGetProcAddress). + +```cpp +template<auto> +struct fex_gen_config { + // Must refer to a function defined manually + const char* loader = "InternalGetProcAddress"; +}; + +template<> +struct fex_gen_config<glBegin> { +}; +``` + +### Guest-side symbol table + +All host-side thunk libraries define a table called `export` listing all thunked functions. Some libraries (notably libGL) require a similar guest-side table to be created to map each function name (as `const char*`) to the corresponding packing function. This can be requested by making the unspecialized `fex_gen_config` inherit from `guest_symbol_table`. The generated symbol table will be named after the containing namespace: + +```cpp +namespace internal_functions { + +template<auto> +struct fex_gen_config : guest_symbol_table { + // Will cause a guest-side symbol table called "internal_functions_symtable" to be generated +}; + +} // end of namespace +``` + +# Update history + +- 17 Sep 2021: Binary function customization parameters are now implemented using inheritance from a tag type. Previously, a boolean member had to be declared. +- 17 Sep 2021: Type-based function customization parameters are now implemented using `using customization_name = type;`. Previously, a member had to be declared where its type would act as the actual parameter. +- 18 Sep 2021: `custom_host_unpack` renamed to `custom_host_impl`. Instead of replacing the `fexfn_unpack_func`, the unpacker is now autogenerated as usual but will call a user-provided `fexfn_impl_func` function instead of the host library function (`fex_ldr_func`). +- 2 Oct 2021: Added tags for callback parameters (`callback_through_user_data` and `callback_stub`) +- 5 Oct 2021: Added tags for guest-side symbol tables +- 6 Oct 2021: Added `returns_guest_pointer` tag +- 8 Oct 2021: Added `guest_only` tag for guest-only functions, which don't need thunks +- 8 Oct 2021: Added `custom_guest_impl` tag +- 30 Oct 2021: Added `callback_guest` tag to callbacks that are only called guest-side \ No newline at end of file diff --git a/results/scraper/fex/1279 b/results/scraper/fex/1279 new file mode 100644 index 000000000..c1368cdcd --- /dev/null +++ b/results/scraper/fex/1279 @@ -0,0 +1,27 @@ +static-pie is incompatible with thunks due to glibc bug +When glibc is initializing it has some allocation functions that are setup at certain times. +These are the `__rtld_` functions located here: https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-minimal.c;h=4e7f11aeabb70f2d50cf767bc54a3c5237574b57;hb=HEAD#l42 + +On executable start the function `__rtld_malloc_init_stubs` will be called to set these to some small helper functions. +This needs to be done since there isn't any state tracking happening yet in glibc so it can't do memory management. +This function gets called from `_dl_start` for the initial set. + +At some point `_dl_main` will call `__rtld_malloc_init_real` which scans the main map and set these pointers to the real allocation function pointers. + +Now in the case of static-pie. This all happens accordingly and works fine. +Then we try to `dlopen` a library. At first glance it works correctly. +You can pull symbols out, you can allocate memory. Seems fine. +Then once that library tries to create a thread, glibc will try allocating some memory using its internal symbols for allocations. +These are now currently set to **!!zero!!**, causing the application to immediately crash. + +This is because even though FEX has started up correctly and set these function pointers, when you dlopen a library there are a bunch of things that happen. +Primarily: +- glibc shared libraries are now loaded in to memory +- ld-linux.so +- libc.so +- libpthread.so +- etc +These libraries now being loaded in to memory have not run through glibc's initialization routines in the expected manner. +This causes the rtld function pointers to now be pointing to zero, which causes the crash. + +This is a glibc bug where they haven't tested a complex use case of {static, static-pie} + dlopen and needs to be resolved on their end. \ No newline at end of file diff --git a/results/scraper/fex/1280 b/results/scraper/fex/1280 new file mode 100644 index 000000000..b71d90fcb --- /dev/null +++ b/results/scraper/fex/1280 @@ -0,0 +1,6 @@ +CI for thunks +Thunks are particularly fragile especially when we have multiple memory allocators flying around. +We need a CI that tests thunks to some extent to make sure we don't break them. + +Particularly need tests that stress thunks that are allocating memory and passing it to the guest. +Hopefully something that is hitting xcb since those libraries allocate quite a bit of memory and pass it to the guest. \ No newline at end of file diff --git a/results/scraper/fex/1297 b/results/scraper/fex/1297 new file mode 100644 index 000000000..312a23438 --- /dev/null +++ b/results/scraper/fex/1297 @@ -0,0 +1,2 @@ +Is this similar like box86 ? +Is this can run wine x86 too? \ No newline at end of file diff --git a/results/scraper/fex/1299 b/results/scraper/fex/1299 new file mode 100644 index 000000000..20dca646b --- /dev/null +++ b/results/scraper/fex/1299 @@ -0,0 +1,3 @@ +Add wayland thunking +Currently trying to thunk a wayland application will likely result in a crash. +Thunk wayland-client and other bits to resolve that. \ No newline at end of file |