diff options
Diffstat (limited to 'results')
856 files changed, 13725 insertions, 0 deletions
diff --git a/results/scraper/fex/100 b/results/scraper/fex/100 new file mode 100644 index 000000000..0761872ef --- /dev/null +++ b/results/scraper/fex/100 @@ -0,0 +1,3 @@ +Declare IR destination register class directly in json +Currently the destination register class is declared in the RA pass. +Change this so it is declared in the JSON file and the RA uses a helper that is generated to pull the register class \ No newline at end of file diff --git a/results/scraper/fex/1000 b/results/scraper/fex/1000 new file mode 100644 index 000000000..56c6e6968 --- /dev/null +++ b/results/scraper/fex/1000 @@ -0,0 +1,5 @@ +Cortex-A78 r0p0 has atomic errata that needs runtime workaround +Needs a `DMB ST` in front of every atomic load acquire instruction that doesn't have release semantics. +r1p0 and r1p1 doesn't need this as TZ will workaround it for us. + +Need to check SoCs and upcoming SoCs to see if any manage to ship r0p0 \ No newline at end of file diff --git a/results/scraper/fex/101 b/results/scraper/fex/101 new file mode 100644 index 000000000..9d6900459 --- /dev/null +++ b/results/scraper/fex/101 @@ -0,0 +1,3 @@ +Clean up vector ops in json +Currently most vector ops declare an additional RegisterSize and ElementSize element in their ops. +This is already declared in the header of each op, pass the argument through to the header rather than having it in each IR specifically \ No newline at end of file diff --git a/results/scraper/fex/103 b/results/scraper/fex/103 new file mode 100644 index 000000000..1b6b274ce --- /dev/null +++ b/results/scraper/fex/103 @@ -0,0 +1,3 @@ +Add IR Op argument register class contraints to enforce validation +Let each argument specify its incoming register class to enforce validation in the validation pass. +Currently we have no way to detect bad IR in this way \ No newline at end of file diff --git a/results/scraper/fex/1034 b/results/scraper/fex/1034 new file mode 100644 index 000000000..c772cfef4 --- /dev/null +++ b/results/scraper/fex/1034 @@ -0,0 +1,4 @@ +Disable thunk when host library doesn't exist +If the host library doesn't exist then disable the thunk and only use the guest libraries. +Necessary in the case that we thunk small libraries that the host likely doesn't have. +OpenFMOD as an example. \ No newline at end of file diff --git a/results/scraper/fex/1035 b/results/scraper/fex/1035 new file mode 100644 index 000000000..86d3199b4 --- /dev/null +++ b/results/scraper/fex/1035 @@ -0,0 +1,2 @@ +LookupCache::Erase does not remove CodePages entry +CodePages are used to store per page blocks lists. While this is not strictly a bug, it can result to excessive invalidation and a slight memory leak. \ No newline at end of file diff --git a/results/scraper/fex/1036 b/results/scraper/fex/1036 new file mode 100644 index 000000000..66729029b --- /dev/null +++ b/results/scraper/fex/1036 @@ -0,0 +1,2 @@ +Drop FEXConfig to ES 2.0 +We don't need GL 3.0. Use ES 2.0 instead to get maximum compatibility. \ No newline at end of file diff --git a/results/scraper/fex/104 b/results/scraper/fex/104 new file mode 100644 index 000000000..fb4ede6b8 --- /dev/null +++ b/results/scraper/fex/104 @@ -0,0 +1,15 @@ +Add IR op metadata tags in json +Initial Metadata: + +- StoreMemory + - Stores to memory. Ensures that even if the op doesn't generate output, that it can't be DCE'd +- Volatile + - Similar to StoreMemory. Even if it doesn't write memory, this is a volatile op that shouldn't be DCE'd + +Architecture specific select of metadata +- ClobbersFlags + - Clobbers host side flags, so if FLAG register class is used, must be spilled around this op +- NecessaryTemps + - Number of temp registers this IR op needs to work. Will allocate a register that its live range starts at this op and then ends at the same op +- PhysicalRegisters - (We need both dest physical colouring and argument physical colouring) + - If this op needs specific physical registers then this is an RA constraint that enforces those registers to be allocated \ No newline at end of file diff --git a/results/scraper/fex/1047 b/results/scraper/fex/1047 new file mode 100644 index 000000000..cd74d8f15 --- /dev/null +++ b/results/scraper/fex/1047 @@ -0,0 +1,14 @@ +'drm/drm.h' file not found +I have libdrm and mesa installed so I'm not sure if/which dependency I'm missing. +``` +[5/43] Building CXX object Source/Tests/LinuxSyscalls/CMakeFiles/LinuxEmulation.dir/x32/IoctlEmulation.cpp.o +FAILED: Source/Tests/LinuxSyscalls/CMakeFiles/LinuxEmulation.dir/x32/IoctlEmulation.cpp.o +/usr/bin/clang++ -DGLOBAL_DATA_DIRECTORY=\"/usr/share/fex-emu/\" -DVIXL_INCLUDE_TARGET_AARCH64=1 -D_M_ARM_64=1 -ISource/Tests/LinuxSyscalls -I../Source/Tests/LinuxSyscalls -I../External/vixl/src -I../External/jemalloc/pregen/include -I../External/cpp-optparse -I../External/imgui -I../External/json-maker -I../External/tiny-json -I../External/xbyak -I../Source -ISource -Igenerated -IExternal/FEXCore/Source -I../External/FEXCore/include -Iinclude -I../External/jemalloc/include -mcpu=native -O3 -DNDEBUG -fomit-frame-pointer -flto=thin -fPIC -Wno-trigraphs -fdiagnostics-color=always -fcolor-diagnostics -Wno-deprecated-enum-enum-conversion -Wall -fno-operator-names -std=gnu++20 -MD -MT Source/Tests/LinuxSyscalls/CMakeFiles/LinuxEmulation.dir/x32/IoctlEmulation.cpp.o -MF Source/Tests/LinuxSyscalls/CMakeFiles/LinuxEmulation.dir/x32/IoctlEmulation.cpp.o.d -o Source/Tests/LinuxSyscalls/CMakeFiles/LinuxEmulation.dir/x32/IoctlEmulation.cpp.o -c ../Source/Tests/LinuxSyscalls/x32/IoctlEmulation.cpp +In file included from ../Source/Tests/LinuxSyscalls/x32/IoctlEmulation.cpp:1: +../Source/Tests/LinuxSyscalls/x32/Ioctl/drm.h:7:10: fatal error: 'drm/drm.h' file not found +#include <drm/drm.h> + ^~~~~~~~~~~ +1 error generated. +``` + +Building on Arch Linux ARM \ No newline at end of file diff --git a/results/scraper/fex/105 b/results/scraper/fex/105 new file mode 100644 index 000000000..386c9bc41 --- /dev/null +++ b/results/scraper/fex/105 @@ -0,0 +1,3 @@ +Have IR pull relevant bits of data from a textual representation +We can do things like `<GPRPair> = CASP <GPRPair>, <GPRPair>, <GPR>` directly in IR definition file rather than having that information encoded with a bunch of arguments. +Would take a decent amount of work to ensure it is correct so this is a longer term goal \ No newline at end of file diff --git a/results/scraper/fex/1075 b/results/scraper/fex/1075 new file mode 100644 index 000000000..dccdd542d --- /dev/null +++ b/results/scraper/fex/1075 @@ -0,0 +1,2 @@ +AOT threads should lower priority +Expectation is to have these run in the background. Lower the priority. \ No newline at end of file diff --git a/results/scraper/fex/1080 b/results/scraper/fex/1080 new file mode 100644 index 000000000..ae5fc5252 --- /dev/null +++ b/results/scraper/fex/1080 @@ -0,0 +1,6 @@ +LUAJit crashes in some games +I've found a couple games that use LUAJit and crash inside of it almost immediately. +Needs to be investigated. + +List of games as I find them again. +* Minit \ No newline at end of file diff --git a/results/scraper/fex/1081 b/results/scraper/fex/1081 new file mode 100644 index 000000000..72a534ea9 --- /dev/null +++ b/results/scraper/fex/1081 @@ -0,0 +1,5 @@ +Implement CLZero +CLZero is a Zen instruction for zeroing a cacheline (and also any poison attributes). +This can be implemented directly with a `DC ZVA` instruction when DCZID_EL0 reports the same size as cacheline size, which is commonly the case. + +Might also work when DCZID_EL0 reports 64byte block arrangement, since we must always report to the guest that we have a 64byte cacheline size. \ No newline at end of file diff --git a/results/scraper/fex/1097 b/results/scraper/fex/1097 new file mode 100644 index 000000000..3e0e24853 --- /dev/null +++ b/results/scraper/fex/1097 @@ -0,0 +1,39 @@ +SIGABRT in VirtuaVerse (Unity/Mono game) +I don't really expect a fix for this as I guess you can't reproduce it without owning the game--although it might happen with other Unity games as well. + +First of all, my host is i.MX8MQ (Cortex-A53) with Debian Bullseye/Sid, Desktop is sway. I have a Debian Bullseye debootstrap rootfs for FEX and I can run glxgears with thunk libs fine at good FPS. + +Executing any of the following yields the same error: +```bash +FEXLoader -R /home/mntmn/emu/debian-amd64 -t ~/src/FEX/Build/Host -- /home/mntmn/emu/debian-amd64/home/mntmn/GOG\ Games/VirtuaVerse/game/VirtuaVerse.x86_64 +FEXLoader -c irint -T 1 -R /home/mntmn/emu/debian-amd64 -t ~/src/FEX/Build/Host -- /home/mntmn/emu/debian-amd64/home/mntmn/GOG\ Games/VirtuaVerse/game/VirtuaVerse.x86_64 +FEXLoader -c irint -T 1 -R /home/mntmn/emu/debian-amd64 -- /home/mntmn/emu/debian-amd64/home/mntmn/GOG\ Games/VirtuaVerse/game/VirtuaVerse.x86_64 +``` + +The error being: + +``` +Found path: /home/mntmn/emu/debian-amd64/home/mntmn/GOG Games/VirtuaVerse/game/VirtuaVerse.x86_64 +Mono path[0] = '/home/mntmn/emu/debian-amd64/home/mntmn/GOG Games/VirtuaVerse/game/VirtuaVerse_Data/Managed' +Mono config path = '/home/mntmn/emu/debian-amd64/home/mntmn/GOG Games/VirtuaVerse/game/VirtuaVerse_Data/Mono/etc' +Thread (nil) may have been prematurely finalized +Receiving unhandled NULL exception +Thread (nil) may have been prematurely finalized +#0 0x00007f93dfe168 in (Unknown) + +Native stacktrace: + + /home/mntmn/emu/debian-amd64/home/mntmn/GOG Games/VirtuaVerse/game/VirtuaVerse_Data/Mono/x86_64/libmono.so(+0x98673) [0x7f66b81673] + [0x7f94b99000] + +Debug info from gdb: + +I refuse to debug myself! +No threads. + +================================================================= +Got a SIGABRT while executing native code. This usually indicates +a fatal error in the mono runtime or one of the native libraries +used by your application. +================================================================= +``` diff --git a/results/scraper/fex/1100 b/results/scraper/fex/1100 new file mode 100644 index 000000000..9d3e73f8c --- /dev/null +++ b/results/scraper/fex/1100 @@ -0,0 +1,3 @@ +Implement 32-bit IRET +Bioshock Infinite requires this. +#1098 Got this game further which uncovered this. \ No newline at end of file diff --git a/results/scraper/fex/1106 b/results/scraper/fex/1106 new file mode 100644 index 000000000..63bd544df --- /dev/null +++ b/results/scraper/fex/1106 @@ -0,0 +1,3 @@ +Saints Row 2 and Saints Row: Gat out of Hell only work in debug builds +These games work in debug builds but a release build causes them to hang on load screens. +Dissect what is the problem. \ No newline at end of file diff --git a/results/scraper/fex/1107 b/results/scraper/fex/1107 new file mode 100644 index 000000000..b665fd84d --- /dev/null +++ b/results/scraper/fex/1107 @@ -0,0 +1,23 @@ +Defer host signal installation until guest installs signal handler +Right now we install all of the host signal handlers up front. +Instead of installing all of them, retain the information and only install with the kernel once the guest has installed one. +Specifically this will need to immediately install the signal handlers that FEX requires, then defer everything else. + +- x86 host needs: SIGILL SIG63 +- AArch64 host needs: SIGBUS SIGILL SIG63 +- We may eventually also need SIGSYS installed up front. + +The rest of the signals can be deferred. +This is important for TTY handoff issues. The kernel changes behaviour of TTY handoff if you have specific signal handlers installed or not. + +```bash +FEXInterpreter /bin/sh +ls +<terminal never gives back the control to user> +``` + +Once signals are correctly deferred then this should be tested again and ensured it is fixed. + +Files: +- Source/Tests/LinuxSyscalls/SignalDelegator.cpp - For signal installation +- External/FEXCore/Source/Interface/Core/JIT/{Arm64, x86_64}/JIT.cpp - For the backends installing signals with `RegisterHostSignalHandler` and `RegisterHostSignalHandlerForGuest` \ No newline at end of file diff --git a/results/scraper/fex/1108 b/results/scraper/fex/1108 new file mode 100644 index 000000000..2b3aa5d6d --- /dev/null +++ b/results/scraper/fex/1108 @@ -0,0 +1,5 @@ +Implement the remaining 32-bit syscalls that we can +We are missing about about 50 of the syscalls. +We can implement most of them immediately. +Lots of random application debugging comes down to catching the missing syscall and implementing. +https://docs.google.com/spreadsheets/d/1SgduuVKLSd9wJbZpaETS9PfjkVZnyFLg40dyigjb1Cw/edit#gid=1655400205 \ No newline at end of file diff --git a/results/scraper/fex/1109 b/results/scraper/fex/1109 new file mode 100644 index 000000000..338cd3ee8 --- /dev/null +++ b/results/scraper/fex/1109 @@ -0,0 +1,9 @@ +Need help compiling for Manjaro ARM +I'm new to the whole chroot idea. I see that we have to mount a `rootfs` for x86_64. I have installed qemu and even debootstrap for installing the chroot. My issue is what comes after that. I don't know how to set up the chroot to be piped through FEX. Can someone push me in the right direction? + +Edit: I also got as far as to try to actually chroot into the rootfs. But I should have known that wasn't going to work. Incompatible binary types. + + +This is also really vague. I don't understand the exact requirements for this to run on an Arch based system. Seems simple enough for debian though. + +I am also getting similar issues to the ones in #997 \ No newline at end of file diff --git a/results/scraper/fex/1114 b/results/scraper/fex/1114 new file mode 100644 index 000000000..5e509ad71 --- /dev/null +++ b/results/scraper/fex/1114 @@ -0,0 +1,4 @@ +Support static-pie +We can nearly support static-pie at this point. +It's just a case of setting up cmake to play nice and fix the couple dlopen things that fex still needs. +Once we do support it then we can end up working in chroot environments. Which would be an interesting proposition. \ No newline at end of file diff --git a/results/scraper/fex/1119 b/results/scraper/fex/1119 new file mode 100644 index 000000000..b65c35a97 --- /dev/null +++ b/results/scraper/fex/1119 @@ -0,0 +1,50 @@ +Walk through personality flags on 32-bit and 64-bit and ensure correct behaviour +Not sure exactly how much this matters but we should double check it. + +Flags to support: +- UNAME26 + - Needs emulation +- ADDR_NO_RANDOMIZE + - Already handled in ELFCodeLoader +- FDPIC_FUNCPTRS + - nop on x86 +- MMAP_PAGE_ZERO + - Allowed but doesn't do anything on x86 +- ADDR_COMPAT_LAYOUT + - Changes allocation to BottomUp instead of top-down + - Would need emulation +- READ_IMPLIES_EXEC + - Needs NX support, which we don't have currently +- ADDR_LIMIT_32BIT + - nop on x86 +- SHORT_INODE + - nop +- WHOLE_SECONDS + - nop +- STICKY_TIMEOUTS + - Causes select, pselect, and ppoll to not modify timeout on signal handler interrupt. + - Passthrough to host kernel makes FEX impl a nop. +- ADDR_LIMIT_3GB + - Changes the upper limit on mmap from 0xffff_e000 to 0xc000_0000 for 32-bit processes + - Needs emulation + +Personalities: +- PER_LINUX32 + - Changes uname result + - Needs emulation +- PER_SVR4/3 +- PER_SCOSVR3/PER_OSR5 +- PER_WYSEV386 +- PER_ISCR4 +- PER_BSD +- PER_SUNOS +- PER_XENIX +- PER_IRIX32 +- PER_IRIXN32 +- PER_IRIX64 +- PER_RISCOS +- PER_SOLARIS +- PER_UW7 +- PER_OSF4 +- PER_HPUX + - nop \ No newline at end of file diff --git a/results/scraper/fex/1127 b/results/scraper/fex/1127 new file mode 100644 index 000000000..9d7fbb456 --- /dev/null +++ b/results/scraper/fex/1127 @@ -0,0 +1,13 @@ +Steamwebhelper burns a few CPU cores and doesn't render on ARM64 +steamwebhelper maxes out 4+ CPU cores on ARM64 and fails to render any content. +This looks like for some reason it is just constantly spinning for work and not getting any. +This doesn't happen on x86-64. It even renders some parts of the UI correctly. + +This doesn't seem to be optimization pass related. Same problem even disabling optimization passes. +From what I can tell it doesn't look like it is syscall related. I've been combing through syscalls finding weird edge cases, but nothing that has affected the behaviour. +Switching to llvmpipe doesn't resolve the issue, so it isn't freedreno/turnip related. +~~Switching to interpreter /might/ resolve the issue, but it runs so slowly that it may just not be passing jobs between threads?~~ +So it looks like it might be a JIT bug? It's being a pain to nail down. + +This happens with the steamwebhelper 64-bit processes. The 32-bit steam side seems to not care. +This is hard to tell if it happens in a standalone chromium process, it uses a lot of CPU time just idling. diff --git a/results/scraper/fex/1148 b/results/scraper/fex/1148 new file mode 100644 index 000000000..7b6a71891 --- /dev/null +++ b/results/scraper/fex/1148 @@ -0,0 +1,3 @@ +Enforce static xxhash library usage +Sometimes FEX pulls in the shared object version. +Enforce the static library instead. \ No newline at end of file diff --git a/results/scraper/fex/1159 b/results/scraper/fex/1159 new file mode 100644 index 000000000..16a671cee --- /dev/null +++ b/results/scraper/fex/1159 @@ -0,0 +1,5 @@ +Implement new syscalls for v5.13-v5.16 +v5.13 added: +444 common landlock_create_ruleset sys_landlock_create_ruleset +445 common landlock_add_rule sys_landlock_add_rule +446 common landlock_restrict_self sys_landlock_restrict_self \ No newline at end of file diff --git a/results/scraper/fex/116 b/results/scraper/fex/116 new file mode 100644 index 000000000..46fb4885d --- /dev/null +++ b/results/scraper/fex/116 @@ -0,0 +1,2 @@ +Syscall Unit tests +We need unit tests for these syscalls to make sure we don't break them. \ No newline at end of file diff --git a/results/scraper/fex/1164 b/results/scraper/fex/1164 new file mode 100644 index 000000000..481e3e933 --- /dev/null +++ b/results/scraper/fex/1164 @@ -0,0 +1,3 @@ +Generate unit tests for LOCK ops that touch flags +We currently don't have unit tests that for LOCK operations and flag setting. +We hit a bug that these weren't generating flags correctly that went unnoticed. \ No newline at end of file diff --git a/results/scraper/fex/1169 b/results/scraper/fex/1169 new file mode 100644 index 000000000..1fb555f19 --- /dev/null +++ b/results/scraper/fex/1169 @@ -0,0 +1,2 @@ +Install to /usr/local +When I install to /usr/local, I get issues registering the binfmt handler. It seems that the path of /usr is hardcoded there. I'm a bit uncomfortable installing all of the binaries directly into /usr/bin, especially when there isn't even an uninstaller. \ No newline at end of file diff --git a/results/scraper/fex/117 b/results/scraper/fex/117 new file mode 100644 index 000000000..e0d5a9c34 --- /dev/null +++ b/results/scraper/fex/117 @@ -0,0 +1,4 @@ +Golang needs VDSO and/or vsyscall +Golang has a bit of assembly for using vdso or vsyscall for gettimeofday. +We don't currently support either of these. +This is necessary if we want to run any golang application. \ No newline at end of file diff --git a/results/scraper/fex/1175 b/results/scraper/fex/1175 new file mode 100644 index 000000000..acbf5f346 --- /dev/null +++ b/results/scraper/fex/1175 @@ -0,0 +1,9 @@ +static-pie currently crashes +This is a tracking issue for upstream problems with static-pie. + +* Currently lld generates relocatable sections with static-pie that glibc crashes on. + * This will be fixed with lld 13.0 when it releases near the end of September +* Currently shared_mutexes crash static and static-pie executables + * This seems to be a quirk with static and weak symbols + * Happens with both gcc and clang + * Theoretically will be fixed with glibc 2.34 which releases around August 1st. \ No newline at end of file diff --git a/results/scraper/fex/1177 b/results/scraper/fex/1177 new file mode 100644 index 000000000..a7258b960 --- /dev/null +++ b/results/scraper/fex/1177 @@ -0,0 +1,7 @@ +DEBUG builds are currently broken with jemalloc overrides +When we build debug, something is trying to pull in malloc symbols that we don't have in jemalloc. + +We should either figure out what symbols the debug libraries want, or disable jemalloc in debug. + +Disabling jemalloc isn't ideal since then we break 32-bit application execution. +We should find what symbols we have failed to override in this case. \ No newline at end of file diff --git a/results/scraper/fex/1189 b/results/scraper/fex/1189 new file mode 100644 index 000000000..6d18e8bdf --- /dev/null +++ b/results/scraper/fex/1189 @@ -0,0 +1,2 @@ +eON games fail to start when RootFS is set +They fail to create a temporary directory for some reason. Should be fixable. \ No newline at end of file diff --git a/results/scraper/fex/1190 b/results/scraper/fex/1190 new file mode 100644 index 000000000..de54b745a --- /dev/null +++ b/results/scraper/fex/1190 @@ -0,0 +1,17 @@ +Offline telemetry report +It will be beneficial to have offline telemetry for FEX for determining things that applications do. +This will be entirely offline and only stored to a file on the local machine. +Three operating modes. Only saves last run of information. + +1. None - Doesn't save the data at all +2. Minimal - Only minimal information about the application (Default) +3. Verbose - Gives some extended information that otherwise wouldn't be saved + +Telemetry information +1) Split locks + - Minimal - Only report that it hits split locks + - Verbose - Save the RIP where the split lock occurred + 2) Uses AVX (with 256bit register) + - Minimal - Simple bool + - Verbose - Which op was used and width + 3) More \ No newline at end of file diff --git a/results/scraper/fex/1195 b/results/scraper/fex/1195 new file mode 100644 index 000000000..c91470f16 --- /dev/null +++ b/results/scraper/fex/1195 @@ -0,0 +1,2 @@ +Add back support to binfmt_misc to non-debian architectures +We're using update-binfmts, which doesn't exist on arch. Need to fix that. \ No newline at end of file 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 diff --git a/results/scraper/fex/13 b/results/scraper/fex/13 new file mode 100644 index 000000000..e0e2e755c --- /dev/null +++ b/results/scraper/fex/13 @@ -0,0 +1,5 @@ +CompileBlocks isn't thread safe +https://github.com/FEX-Emu/FEX/blob/master/External/FEXCore/Source/Interface/Core/Core.cpp#L475 +This function is called from multiple guest threads, which is fine except that the FrontendDecoder object is shared and not thread safe. +Best way to work around this issue would be to give each thread object its own FrontendDecoder object. +This way multiple threads can be compiling code as it pleases \ No newline at end of file diff --git a/results/scraper/fex/130 b/results/scraper/fex/130 new file mode 100644 index 000000000..cba096488 --- /dev/null +++ b/results/scraper/fex/130 @@ -0,0 +1,2 @@ +Improve coverage of syscalls +Someone just needs to spend a day going through all the syscalls that can end up just being a passthrough \ No newline at end of file diff --git a/results/scraper/fex/1313 b/results/scraper/fex/1313 new file mode 100644 index 000000000..60695215e --- /dev/null +++ b/results/scraper/fex/1313 @@ -0,0 +1,3 @@ +JITSymbols: Allow grouping JIT symbol ranges by guest library name. +This will be useful to inform what library is taking the most CPU time. +Can be used to inform what libraries to thunk, or if we are spending a lot of time in the guest side of a thunk. \ No newline at end of file diff --git a/results/scraper/fex/1318 b/results/scraper/fex/1318 new file mode 100644 index 000000000..6ca3108b3 --- /dev/null +++ b/results/scraper/fex/1318 @@ -0,0 +1 @@ +Support Ubuntu 18.04 for Nvidia Jetson diff --git a/results/scraper/fex/1319 b/results/scraper/fex/1319 new file mode 100644 index 000000000..e602a0b61 --- /dev/null +++ b/results/scraper/fex/1319 @@ -0,0 +1,9 @@ +[regression] JIT assertion in glxgears and other content +Simple content like glxgears has been failing some vixl assertions in debug builds recently: +``` +Assertion failed (rd.IsW()) +in /home/tony/projects/FEX/External/vixl/src/aarch64/assembler-aarch64.cc, line 4584 +Aborted +``` + +Reverting cffd10d0 fixes the issue. CC @Sonicadvance1 diff --git a/results/scraper/fex/1320 b/results/scraper/fex/1320 new file mode 100644 index 000000000..b6d7d1cd4 --- /dev/null +++ b/results/scraper/fex/1320 @@ -0,0 +1,51 @@ +[question] How to run steam on switch? +``` +[alarm@alarm ~]$ /usr/lib/steam/bin_steam.sh +Running Steam on ubuntu 21.04 64-bit +STEAM_RUNTIME is enabled automatically +Steam runtime environment up-to-date! +Steam client's requirements are satisfied +WARNING: Using default/fallback debugger launch +/home/alarm/.local/share/Steam/ubuntu12_32/steam +WARNING: setlocale('en_US.UTF-8') failed, using locale: 'C'. International characters may not work. +[2021-10-18 23:06:49] Startup - updater built Oct 13 2021 19:47:06 +Installing breakpad exception handler for appid(steam)/version(1634158817) +libGL error: No matching fbConfigs or visuals found +libGL error: failed to load driver: swrast +SteamUpdateUI: An X Error occurred +X Error of failed request: BadValue (integer parameter out of range for operation) +Major opcode of failed request: 150 (GLX) +Minor opcode of failed request: 3 (X_GLXCreateContext) +Value in failed request: 0x0 +Serial number of failed request: 34 +xerror_handler: X failed, continuing +Looks like steam didn't shutdown cleanly, scheduling immediate update check +[2021-10-18 23:08:19] Loading cached metrics from disk (/home/alarm/.local/share/Steam/package/steam_client_metrics.bin) +[2021-10-18 23:08:19] Failed to load cached hosts file (File 'update_hosts_cached.vdf' not found), using defaults +[2021-10-18 23:08:19] Using the following download hosts for Public, Realm steamglobal +[2021-10-18 23:08:19] 1. http://media.steampowered.com, /client/, Realm 'steamglobal', weight was 1, source = 'baked in' +Installing breakpad exception handler for appid(steam)/version(1634158817) +[2021-10-18 23:08:19] Checking for update on startup +[2021-10-18 23:08:19] Checking for available updates... +[2021-10-18 23:08:20] Downloading manifest: http://media.steampowered.com/client/steam_client_ubuntu12 +Installing breakpad exception handler for appid(steam)/version(1634158817) +[2021-10-18 23:08:21] Download skipped: /client/steam_client_ubuntu12 version 1634158817, installed version 1634158817, existing pending version 0 +[2021-10-18 23:08:21] Nothing to do +[2021-10-18 23:08:21] Verifying installation... +[2021-10-18 23:08:21] Performing checksum verification of executable files +[2021-10-18 23:08:27] Verification complete +Loaded SDL version 2.0.17-6744061 +/usr/share/themes/Breeze/gtk-2.0/widgets/entry:70: error: unexpected identifier `direction', expected character `}' + +(steam:14233): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita", +/usr/share/themes/Breeze/gtk-2.0/widgets/styles:36: error: invalid string constant "combobox_entry", expected valid string constant +libGL error: No matching fbConfigs or visuals found +libGL error: failed to load driver: swrast +Steam: An X Error occurred +X Error of failed request: BadMatch (invalid parameter attributes) +Major opcode of failed request: 150 +Serial number of failed request: 36 +xerror_handler: X failed, continuing +/home/alarm/.local/share/Steam/steam.sh: line 785: 14233 Segmentation fault (core dumped) $STEAM_DEBUGGER $DEBUGGER_ARGS "$STEAMROOT/$STEAMEXEPATH" "$@" + +``` \ No newline at end of file diff --git a/results/scraper/fex/1322 b/results/scraper/fex/1322 new file mode 100644 index 000000000..17eef0bd0 --- /dev/null +++ b/results/scraper/fex/1322 @@ -0,0 +1,10 @@ +FEXConfig: "Most likely this is a multi-threaded client and XInitThreads has not been called" +I tried to run FEXConfig to configure FEX, but I got this +``` +[xcb] Unknown sequence number while processing queue +[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called +[xcb] Aborting, sorry about that. +FEXConfig: xcb_io.c:269: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. +Aborted (core dumped) +``` +I had a black screen flash before dumping this. \ No newline at end of file diff --git a/results/scraper/fex/1323 b/results/scraper/fex/1323 new file mode 100644 index 000000000..a8406252b --- /dev/null +++ b/results/scraper/fex/1323 @@ -0,0 +1,8 @@ +"Current RootFS path set to '' " when passing RootFS manually +My command is `Bin/FEXLoader -R ~/D*/WINE ~/D*/WINE/bin/winecfg`. However, it fails with +``` +Invalid or Unsupported elf file. +This is likely due to a misconfigured x86-64 RootFS +Current RootFS path set to '' +RootFS path doesn't exist. This is required on AArch64 hosts +``` \ No newline at end of file diff --git a/results/scraper/fex/1324 b/results/scraper/fex/1324 new file mode 100644 index 000000000..607484db9 --- /dev/null +++ b/results/scraper/fex/1324 @@ -0,0 +1,2 @@ +Chrooting fails with `command not found` +`sudo chroot ~/D*/WINE` fails with `chroot: failed to run command '/bin/bash': No such file or directory` \ No newline at end of file diff --git a/results/scraper/fex/1326 b/results/scraper/fex/1326 new file mode 100644 index 000000000..a95e4dea4 --- /dev/null +++ b/results/scraper/fex/1326 @@ -0,0 +1,6 @@ +Statically compile FEX? +Is there a way to statically compile FEX, so it does not need the presence of the aarch64 loader, similar to QEMU? I tried `CC=clang CXX=clang++ LD=ld cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DENABLE_LTO=False -DENABLE_STATIC_PIE=True -DBUILD_TESTS=False -DENABLE_ASSERTIONS=False -G Ninja ..`, but it failed with +``` +CMake Error at CMakeLists.txt:211 (message): + Couldn't compile static-pie test. Static-pie can't be enabled! +``` \ No newline at end of file diff --git a/results/scraper/fex/1330 b/results/scraper/fex/1330 new file mode 100644 index 000000000..fd44f9204 --- /dev/null +++ b/results/scraper/fex/1330 @@ -0,0 +1,2 @@ +micro crashes +Micro, a text editor written in Go, crashes. \ No newline at end of file diff --git a/results/scraper/fex/1331 b/results/scraper/fex/1331 new file mode 100644 index 000000000..91d853ae9 --- /dev/null +++ b/results/scraper/fex/1331 @@ -0,0 +1,2 @@ +Wine32 works, but not Wine64 +Using a wine64 prefix, running anything under wine fails with `alloc_pages_vprot: Assertion `end <= pages_vprot_size << pages_vprot_shift' failed`. However, wine32 works fine. \ No newline at end of file diff --git a/results/scraper/fex/1332 b/results/scraper/fex/1332 new file mode 100644 index 000000000..5b4505453 --- /dev/null +++ b/results/scraper/fex/1332 @@ -0,0 +1,3 @@ +Add support for long jumps using veneer pools +For AOT codegen we will want to ensure all of it fits in to a single code region. +Add support for veneer pools so we can long jump more than 128MB. \ No newline at end of file diff --git a/results/scraper/fex/1334 b/results/scraper/fex/1334 new file mode 100644 index 000000000..152a2fb76 --- /dev/null +++ b/results/scraper/fex/1334 @@ -0,0 +1,8 @@ +Config: Environment loader not hooked up to `ArgumentHandler` +Brought up by #1330. +Currently the `ArgumentHandler` function is only wired up for textual arguments passed through FEXLoader's arguments. +Environment variables need the same treatment. +eg: `FEX_CORE=irint` should work but right now it requires `FEX_CORE=0` +Same issue with FEX_SMCCHECKS. + +These are the only two options that currently rely on this feature. \ No newline at end of file diff --git a/results/scraper/fex/1335 b/results/scraper/fex/1335 new file mode 100644 index 000000000..7b1b1c405 --- /dev/null +++ b/results/scraper/fex/1335 @@ -0,0 +1,3 @@ +Some wine games might need ptrace +https://bugzilla.kernel.org/show_bug.cgi?id=200965 +https://bugs.winehq.org/show_bug.cgi?id=46472 \ No newline at end of file diff --git a/results/scraper/fex/1355 b/results/scraper/fex/1355 new file mode 100644 index 000000000..1189d5fdf --- /dev/null +++ b/results/scraper/fex/1355 @@ -0,0 +1,4 @@ +Support ADX +Easy enough to support as it is only two instructions. +Supported on all x86-64 major processors now. +https://en.wikipedia.org/wiki/Intel_ADX \ No newline at end of file diff --git a/results/scraper/fex/136 b/results/scraper/fex/136 new file mode 100644 index 000000000..805186b44 --- /dev/null +++ b/results/scraper/fex/136 @@ -0,0 +1,2 @@ +Flesh out const-prop pass +Currently const-prop doesn't hit every op so it could be doing better \ No newline at end of file diff --git a/results/scraper/fex/137 b/results/scraper/fex/137 new file mode 100644 index 000000000..c4220998c --- /dev/null +++ b/results/scraper/fex/137 @@ -0,0 +1 @@ +cmake Check if nasm is installed for test generation diff --git a/results/scraper/fex/1374 b/results/scraper/fex/1374 new file mode 100644 index 000000000..755783038 --- /dev/null +++ b/results/scraper/fex/1374 @@ -0,0 +1,4 @@ +Incorrect orbital familiars movement in The Binding of Isaac: Rebirth +Orbital familiars are supposed to spin in a circular motion around the main character. In FEX however they bounce around in a semi-circle, changing movement direction each time they have moved by 180°. This can easily be reproduced within few seconds in challenge 6 ("Solar System"), where the main character starts with a number of orbital familiars that each have this problem. + +This also affects enemy groups that normally arrange in circles, such as the pink ring flies, which arrange in a semi-circle in FEX instead. diff --git a/results/scraper/fex/138 b/results/scraper/fex/138 new file mode 100644 index 000000000..6f669e650 --- /dev/null +++ b/results/scraper/fex/138 @@ -0,0 +1 @@ +cmake Check if boost is installed for test generation diff --git a/results/scraper/fex/1389 b/results/scraper/fex/1389 new file mode 100644 index 000000000..8d818cc6e --- /dev/null +++ b/results/scraper/fex/1389 @@ -0,0 +1,5 @@ +FEX-Emu not working anymore inside Termux PRoot container +Distro:- Arch Linux ARM64 (running on Termux PRoot container) + +Error:- +`[ERROR] [Unsupported] FEX mapped to lower 32bits! Exiting!` \ No newline at end of file diff --git a/results/scraper/fex/139 b/results/scraper/fex/139 new file mode 100644 index 000000000..0741e3bc0 --- /dev/null +++ b/results/scraper/fex/139 @@ -0,0 +1 @@ +cmake check for GLFW is installed for graphical debugger diff --git a/results/scraper/fex/14 b/results/scraper/fex/14 new file mode 100644 index 000000000..b654992fe --- /dev/null +++ b/results/scraper/fex/14 @@ -0,0 +1,3 @@ +Clean up CVT IR Ops and OpDispatcher function names. +Both the IR ops and x86 functions for CVT can end up being confusing and prone to bugs. +Clean it up and make it more apparent what they are supposed to do. \ No newline at end of file diff --git a/results/scraper/fex/140 b/results/scraper/fex/140 new file mode 100644 index 000000000..0355f19ba --- /dev/null +++ b/results/scraper/fex/140 @@ -0,0 +1 @@ +cmake check for epoxy is installed for graphical debugger diff --git a/results/scraper/fex/141 b/results/scraper/fex/141 new file mode 100644 index 000000000..ab42668d9 --- /dev/null +++ b/results/scraper/fex/141 @@ -0,0 +1,2 @@ +Enable -U option by default +Need to ensure that TestHarnessRunner still doesn't enable it. Those tests rely on some explicit address locations. \ No newline at end of file diff --git a/results/scraper/fex/1414 b/results/scraper/fex/1414 new file mode 100644 index 000000000..3eb8586bc --- /dev/null +++ b/results/scraper/fex/1414 @@ -0,0 +1 @@ +Update vixl fork to get SVE diff --git a/results/scraper/fex/1415 b/results/scraper/fex/1415 new file mode 100644 index 000000000..6157e6e16 --- /dev/null +++ b/results/scraper/fex/1415 @@ -0,0 +1,24 @@ +Find a way to support /proc/self/exe in a cleaner way +This is a byproduct of how binfmt_misc works and it seems like an oversight of the Linux kernel. + +First, in a regular environment. +The Linux kernel loads the ELF. +If it is a static ELF, it can skip loading the interpreter. +If it is a dynamic ELF then it loads the interpreter and executes that. +At the end of the execution, `/proc/self/exe` points to the initial ELF execve, regardless of interpreter. + +In the case of binfmt_misc, the interpreter is the binfmt_misc ELF. +In this case `/proc/self/exe` is set to the binfmt_misc interpreter rather than the initial ELF passed to execve. + +**Kernel workaround?** +Seems like an oversight that the kernel doesn't set this up correctly. +in `fs/exec.c` the kernel sets the exe file with `set_mm_exe_file(bprm->mm, bprm->file);` +A kernel workaround would likely be at the end of that function there is a `if (bprm->have_execfd)` then the kernel can do a `set_mm_exe_file(bprm->mm, bprm->execfd);` + +In the userspace there is currently only two ways to set this file. +1) `prctl(PR_SET_MM, PR_SET_MM_EXE_FILE, fd, 0, 0);` +The problem with this approach is that this requires the CAP_SYS_RESOURCE feature. Which gives permission to a lot of things. +Additionally we must unmap the original exe before setting the new exe file. The kernel checks the exe mapping to ensure it is completely unmapped. This is a bit of a pain since it breaks execution back through libc shutdown. +2) `prctl(PR_SET_MM, PR_SET_MM_MAP, ...);` +This requires the loader application to setup a checkpoint/restore namespace. Which isn't always available anyway. +Same unmapping problem as the other prctl diff --git a/results/scraper/fex/142 b/results/scraper/fex/142 new file mode 100644 index 000000000..6b37b45e2 --- /dev/null +++ b/results/scraper/fex/142 @@ -0,0 +1,3 @@ +Syscall host->guest versioning +Version syscalls based on implemented in host kernel. +Change the uname result to a version of guest that matches host kernel version and syscalls supported. \ No newline at end of file diff --git a/results/scraper/fex/1423 b/results/scraper/fex/1423 new file mode 100644 index 000000000..df26b2154 --- /dev/null +++ b/results/scraper/fex/1423 @@ -0,0 +1,97 @@ +failure to build with -DBUILD_TESTS=True on 18.04 +I shoved a few PPAs into 18.04 to attempt to build it on a Jetson Nano - are the following errors a result of my dependencies probably being a mess, or is this something that can be fixed on FEX's end? + +Relevant dependencies below, let me know if I'm missing anything: +```bash +cobalt@nano-sd:~/FEX/Build$ cmake --version +cmake version 3.22.0 + +CMake suite maintained and supported by Kitware (kitware.com/cmake). + +cobalt@nano-sd:~/FEX/Build$ clang-13 --version +Ubuntu clang version 13.0.1-++20211124042925+19b8368225dc-1~exp1~20211124043458.31 +Target: aarch64-unknown-linux-gnu +Thread model: posix +InstalledDir: /usr/bin +cobalt@nano-sd:~/FEX/Build$ +``` +Also I've got `libstdc++-11-dev` and `libstdc++6`, llvm.org mentioned those were needed from a PPA. + +Full log: +```bash +cobalt@nano-sd:~/FEX/Build$ CC=clang-13 CXX=clang++-13 cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DENABLE_LTO=True -DBUILD_TESTS=False -G Ninja .. +-- The C compiler identification is Clang 13.0.1 +-- The CXX compiler identification is Clang 13.0.1 +-- Detecting C compiler ABI info +-- Detecting C compiler ABI info - done +-- Check for working C compiler: /usr/bin/clang-13 - skipped +-- Detecting C compile features +-- Detecting C compile features - done +-- Detecting CXX compiler ABI info +-- Detecting CXX compiler ABI info - done +-- Check for working CXX compiler: /usr/bin/clang++-13 - skipped +-- Detecting CXX compile features +-- Detecting CXX compile features - done +-- Performing Test ENUM_ENUM_WARNING +-- Performing Test ENUM_ENUM_WARNING - Success +-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") +-- Found Python: /usr/bin/python3.8 (found suitable version "3.8.6", minimum required is "3.0") found components: Interpreter +-- xxHash not found. Using Externals +-- Version: 7.1.3 +-- Build type: RELEASE +-- CXX_STANDARD: 20 +-- Performing Test has_std_20_flag +-- Performing Test has_std_20_flag - Success +-- Performing Test has_std_2a_flag +-- Performing Test has_std_2a_flag - Success +-- Performing Test SUPPORTS_USER_DEFINED_LITERALS +-- Performing Test SUPPORTS_USER_DEFINED_LITERALS - Success +-- Performing Test FMT_HAS_VARIANT +-- Performing Test FMT_HAS_VARIANT - Success +-- Required features: cxx_variadic_templates +-- Performing Test HAS_NULLPTR_WARNING +-- Performing Test HAS_NULLPTR_WARNING - Success +-- Looking for strtod_l +-- Looking for strtod_l - not found +-- Performing Test GCC_COLOR +-- Performing Test GCC_COLOR - Success +-- Performing Test CLANG_COLOR +-- Performing Test CLANG_COLOR - Success +-- Performing Test COMPILER_SUPPORTS_CPU_TYPE +-- Performing Test COMPILER_SUPPORTS_CPU_TYPE - Success +-- Found Git: /usr/bin/git (found version "2.17.1") +-- Configuring done +-- Generating done +-- Build files have been written to: /home/cobalt/FEX/Build + + +cobalt@nano-sd:~/FEX/Build$ ninja +[0/2] Re-checking globbed directories... +[69/327] Building CXX object External/imgui/CMakeFiles/imgui.dir/imgui_widgets.cpp.o +/home/cobalt/FEX/External/imgui/imgui_widgets.cpp:5415:98: warning: bitwise operation between different enumeration types ('ImGuiTreeNodeFlags_' and 'ImGuiTreeNodeFlagsPrivate_') is deprecated [-Wdeprecated-enum-enum-conversion] + flags |= ImGuiTreeNodeFlags_CollapsingHeader | (p_open ? ImGuiTreeNodeFlags_AllowItemOverlap | ImGuiTreeNodeFlags_ClipLabelForTrailingButton : 0); + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +1 warning generated. +[75/327] Building CXX object Source/Tools/FEX...emon/CMakeFiles/FEXMountDaemon.dir/Main.cpp.o +FAILED: Source/Tools/FEXMountDaemon/CMakeFiles/FEXMountDaemon.dir/Main.cpp.o +/usr/bin/clang++-13 -DENABLE_JEMALLOC=1 -DGLOBAL_DATA_DIRECTORY=\"/usr/share/fex-emu/\" -D_M_ARM_64=1 -I/home/cobalt/FEX/Build/Source/Tools/FEXMountDaemon -I/home/cobalt/FEX/Source/Tools/FEXMountDaemon -I/home/cobalt/FEX/External/jemalloc/pregen/include -I/home/cobalt/FEX/External/vixl/src -I/home/cobalt/FEX/External/xxhash -I/home/cobalt/FEX/External/cpp-optparse -I/home/cobalt/FEX/External/imgui -I/home/cobalt/FEX/External/json-maker -I/home/cobalt/FEX/External/tiny-json -I/home/cobalt/FEX/External/xbyak -I/home/cobalt/FEX/Source -I/home/cobalt/FEX/Build/Source -mcpu=cortex-a57 -O3 -DNDEBUG -fomit-frame-pointer -flto=thin -fPIE -Wno-trigraphs -fdiagnostics-color=always -fcolor-diagnostics -Wno-deprecated-enum-enum-conversion -Wall -std=gnu++20 -MD -MT Source/Tools/FEXMountDaemon/CMakeFiles/FEXMountDaemon.dir/Main.cpp.o -MF Source/Tools/FEXMountDaemon/CMakeFiles/FEXMountDaemon.dir/Main.cpp.o.d -o Source/Tools/FEXMountDaemon/CMakeFiles/FEXMountDaemon.dir/Main.cpp.o -c /home/cobalt/FEX/Source/Tools/FEXMountDaemon/Main.cpp +/home/cobalt/FEX/Source/Tools/FEXMountDaemon/Main.cpp:78:24: error: no member named 'gettid' in the global namespace + EPollThreadTID = ::gettid(); + ~~^ +/home/cobalt/FEX/Source/Tools/FEXMountDaemon/Main.cpp:125:5: error: use of undeclared identifier 'tgkill' + tgkill(::getpid(), EPollThreadTID, SIGUSR1); + ^ +/home/cobalt/FEX/Source/Tools/FEXMountDaemon/Main.cpp:143:25: error: no member named 'gettid' in the global namespace + SocketThreadTID = ::gettid(); + ~~^ +/home/cobalt/FEX/Source/Tools/FEXMountDaemon/Main.cpp:285:5: error: use of undeclared identifier 'tgkill' + tgkill(::getpid(), SocketThreadTID, SIGUSR1); + ^ +4 errors generated. +[80/327] Building CXX object External/FEXCore...ir/Interface/Core/Interpreter/VectorOps.cpp.o +/home/cobalt/FEX/External/FEXCore/Source/Interface/Core/Interpreter/VectorOps.cpp:1404:11: warning: unused variable 'OpSize' [-Wunused-variable] + uint8_t OpSize = IROp->Size; + ^ +1 warning generated. +ninja: build stopped: subcommand failed. +``` \ No newline at end of file diff --git a/results/scraper/fex/1429 b/results/scraper/fex/1429 new file mode 100644 index 000000000..5bf31467c --- /dev/null +++ b/results/scraper/fex/1429 @@ -0,0 +1,4 @@ +F1: 2015 launcher thinks it is running on a Mac +When it starts running under FEX the game has a popup saying something along the lines of "This Mac is unsupported" + +We should figure out why the game thinks it is running on a Mac \ No newline at end of file diff --git a/results/scraper/fex/143 b/results/scraper/fex/143 new file mode 100644 index 000000000..7866f001e --- /dev/null +++ b/results/scraper/fex/143 @@ -0,0 +1,7 @@ +OverlayFS filesystem emulation +We need better filesystem emulation for x86 specific data that will appear + +- [x] `/proc/cpuinfo` - Support generating this on the fly based on emulated CPUID +- [ ] `/proc/self` - Fairly large folder of various information +- [ ] `/sys/devices/system/cpu/online` Currently we state this as only 1 core. We should allow this to be configurable and default to host core count +- [ ] Find more that expose x86 data (libnuma has some things) \ No newline at end of file diff --git a/results/scraper/fex/144 b/results/scraper/fex/144 new file mode 100644 index 000000000..cda70e64d --- /dev/null +++ b/results/scraper/fex/144 @@ -0,0 +1,3 @@ +Support config from environment variables +When launching from binfmt_misc we won't have the luxury of arguments. +Need to support some way to pass via environment \ No newline at end of file diff --git a/results/scraper/fex/1441 b/results/scraper/fex/1441 new file mode 100644 index 000000000..7e195abcb --- /dev/null +++ b/results/scraper/fex/1441 @@ -0,0 +1,4 @@ +FEXMountDaemon spams cmsg messages +This means a bunch of subprocesses aren't getting their pipes watched. +Resolve this issue. +Usually isn't a problem since the primary process that launched FEXMountDaemon stays alive. \ No newline at end of file diff --git a/results/scraper/fex/1450 b/results/scraper/fex/1450 new file mode 100644 index 000000000..c33865c9f --- /dev/null +++ b/results/scraper/fex/1450 @@ -0,0 +1,27 @@ +no member named '__sem_otime_high' in 'semid_ds' +Looks like a glibc and kernel desync. Needs to get investigated. +``` +now stuck in +../Source/Tests/LinuxSyscalls/x64/Types.h:83:11: error: no member named '__sem_otime_high' in 'semid_ds' + buf.__sem_otime_high = sem_otime_high; +Loads of these? +skmp@mangie:~/projects/FEX/build$ uname -a +Linux mangie.hosts.hn.nilware.io 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux +skmp@mangie:~/projects/FEX/build$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04.3 LTS +Release: 20.04 +Codename: focal +uhoh +#ifndef _M_ARM_64 + // AArch64 doesn't have these legacy high variables + buf.__sem_otime_high = sem_otime_high; + buf.__sem_ctime_high = sem_ctime_high; +#endif +apparently, x86_64 doesn't either? +yes +those ifdefs seem broken +Sonicadvance1 — Today at 4:33 AM +Create an issue report about it. Will need to double check the kernel interface and see if this is a mismatch between glibc and kernel +``` \ No newline at end of file diff --git a/results/scraper/fex/1457 b/results/scraper/fex/1457 new file mode 100644 index 000000000..4a12efb16 --- /dev/null +++ b/results/scraper/fex/1457 @@ -0,0 +1,56 @@ +Broken build on Ubuntu 20.04 (565d1e27d75a51223b8f48b618ec913320f836e0) +Tested commit: 565d1e27d75a51223b8f48b618ec913320f836e0 +This seems unrelated to the previous problem I was having + +``` +In file included from ../Source/Tests/LinuxSyscalls/x32/IoctlEmulation.cpp:1: +In file included from ../Source/Tests/LinuxSyscalls/x32/Ioctl/drm.h:5: +In file included from ../Source/Tests/LinuxSyscalls/x32/Types.h:12: +In file included from /usr/include/x86_64-linux-gnu/asm/ipcbuf.h:1: +/include/asm-generic/ipcbuf.h:21:2: error: unknown type name '__kernel_key_t' + __kernel_key_t key; + ^ +/include/asm-generic/ipcbuf.h:22:2: error: unknown type name '__kernel_uid32_t' + __kernel_uid32_t uid; + ^ +/include/asm-generic/ipcbuf.h:23:2: error: unknown type name '__kernel_gid32_t' + __kernel_gid32_t gid; + ^ +/include/asm-generic/ipcbuf.h:24:2: error: unknown type name '__kernel_uid32_t' + __kernel_uid32_t cuid; + ^ +/include/asm-generic/ipcbuf.h:25:2: error: unknown type name '__kernel_gid32_t' + __kernel_gid32_t cgid; + ^ +/include/asm-generic/ipcbuf.h:26:2: error: unknown type name '__kernel_mode_t' + __kernel_mode_t mode; + ^ +/include/asm-generic/ipcbuf.h:28:35: error: use of undeclared identifier '__kernel_mode_t' + unsigned char __pad1[4 - sizeof(__kernel_mode_t)]; + ^ +/include/asm-generic/ipcbuf.h:31:2: error: unknown type name '__kernel_ulong_t' + __kernel_ulong_t __unused1; + ^ +/include/asm-generic/ipcbuf.h:32:2: error: unknown type name '__kernel_ulong_t' + __kernel_ulong_t __unused2; + ^ +In file included from ../Source/Tests/LinuxSyscalls/x32/IoctlEmulation.cpp:1: +In file included from ../Source/Tests/LinuxSyscalls/x32/Ioctl/drm.h:5: +In file included from ../Source/Tests/LinuxSyscalls/x32/Types.h:13: +In file included from /usr/include/x86_64-linux-gnu/asm/shmbuf.h:6: +/include/asm-generic/shmbuf.h:29:2: error: unknown type name '__kernel_time_t' + __kernel_time_t shm_atime; /* last attach time */ + ^ +/include/asm-generic/shmbuf.h:30:2: error: unknown type name '__kernel_time_t' + __kernel_time_t shm_dtime; /* last detach time */ + ^ +/include/asm-generic/shmbuf.h:31:2: error: unknown type name '__kernel_time_t' + __kernel_time_t shm_ctime; /* last change time */ + ^ +/include/asm-generic/shmbuf.h:40:2: error: unknown type name '__kernel_pid_t' + __kernel_pid_t shm_cpid; /* pid of creator */ + ^ +/include/asm-generic/shmbuf.h:41:2: error: unknown type name '__kernel_pid_t' + __kernel_pid_t shm_lpid; /* pid of last operator */ + +``` \ No newline at end of file diff --git a/results/scraper/fex/1458 b/results/scraper/fex/1458 new file mode 100644 index 000000000..a04c0c289 --- /dev/null +++ b/results/scraper/fex/1458 @@ -0,0 +1,15 @@ +LTO build (default) broken on ubuntu 20.04 +Default build configuration leads to the following. Disabling LTO fixes the build + +``` +FAILED: Bin/Opt +: && /usr/bin/clang++ -mcx16 -march=native -O2 -g -DNDEBUG -fno-omit-frame-pointer -flto=thin -fPIE -pie Source/Tools/CMakeFiles/Opt.dir/Opt.cpp.o -o Bin/Opt External/FEXCore/Source/libFEXCore.a Source/Common/libCommon.a Source/CommonCore/libCommonCore.a -lpthread External/cpp-optparse/libcpp-optparse.a External/json-maker/libjson-maker.a External/FEXCore/Source/libFEXCore.a External/FEXCore/Source/libFEXCore_Base.a External/fmt/libfmt.a External/vixl/src/libvixl.a -ldl External/xxhash/libxxhash.a External/tiny-json/libtiny-json.a -lpthread && : +/usr/bin/ld: error: Failed to link module External/FEXCore/Source/libFEXCore.a.llvm.80876708.jemalloc.c: Expected at most one ThinLTO module per bitcode file +clang: error: linker command failed with exit code 1 (use -v to see invocation) +[7/23] Linking CXX executable Bin/UnitTestGenerator +FAILED: Bin/UnitTestGenerator +: && /usr/bin/clang++ -mcx16 -march=native -O2 -g -DNDEBUG -fno-omit-frame-pointer -flto=thin -fPIE -pie Source/Tests/CMakeFiles/UnitTestGenerator.dir/UnitTestGenerator.cpp.o -o Bin/UnitTestGenerator External/FEXCore/Source/libFEXCore.a Source/Common/libCommon.a Source/CommonCore/libCommonCore.a -lpthread External/cpp-optparse/libcpp-optparse.a External/json-maker/libjson-maker.a External/FEXCore/Source/libFEXCore.a External/FEXCore/Source/libFEXCore_Base.a External/fmt/libfmt.a External/vixl/src/libvixl.a -ldl External/xxhash/libxxhash.a External/tiny-json/libtiny-json.a -lpthread && : +/usr/bin/ld: error: Failed to link module External/FEXCore/Source/libFEXCore.a.llvm.80876708.jemalloc.c: Expected at most one ThinLTO module per bitcode file +clang: error: linker command failed with exit code 1 (use -v to see invocation) +[10/23] Building CXX object Source/Tests/LinuxSyscalls/CMakeFiles/LinuxEmulation.dir/x32/IoctlEmulation.cpp.o +``` \ No newline at end of file diff --git a/results/scraper/fex/1459 b/results/scraper/fex/1459 new file mode 100644 index 000000000..a15d82dcf --- /dev/null +++ b/results/scraper/fex/1459 @@ -0,0 +1,4 @@ +Minit has some sort of crash right at the start +Right at the start the engine throws some crash message. +Lua maybe? +https://store.steampowered.com/app/609490/Minit/ \ No newline at end of file diff --git a/results/scraper/fex/146 b/results/scraper/fex/146 new file mode 100644 index 000000000..ffeb1af70 --- /dev/null +++ b/results/scraper/fex/146 @@ -0,0 +1,5 @@ +Convert all string formatting to {fmt} +Rather than `printf` and `cout` everywhere, [{fmt}](https://fmt.dev/latest/index.html) is the future + +It's an implementation of std::format that works in versions of c++ before c++20. By standardising on {fmt} now, we can easily switch to `std::format` later. + diff --git a/results/scraper/fex/1470 b/results/scraper/fex/1470 new file mode 100644 index 000000000..7dbd89e87 --- /dev/null +++ b/results/scraper/fex/1470 @@ -0,0 +1,5 @@ +Build failing +Environment:- Arch Linux ARM64 (Termux PRoot container) + +Error log:- +[Log.txt](https://github.com/FEX-Emu/FEX/files/7779418/Log.txt) diff --git a/results/scraper/fex/1472 b/results/scraper/fex/1472 new file mode 100644 index 000000000..62e7b1a9e --- /dev/null +++ b/results/scraper/fex/1472 @@ -0,0 +1,2 @@ +Dirt 4 crash when getting in to the menu. +Crashes with `[ASSERT][6165745224826][128117.128509] Access to context item went over member size` After signing in and the menu items start loading. \ No newline at end of file diff --git a/results/scraper/fex/1473 b/results/scraper/fex/1473 new file mode 100644 index 000000000..8f1c43270 --- /dev/null +++ b/results/scraper/fex/1473 @@ -0,0 +1,4 @@ +Cities: Skylines crashes once getting to main menu +Crashes with SIGSEGV trying to access address zero. +Does this after opening and closing `/dev/zero` weirdly. +The game also seems to use MAP_32BIT to map executable code regions. Could be an issue with our MAP_32BIT emulation or could just be an SMC problem. \ No newline at end of file diff --git a/results/scraper/fex/1474 b/results/scraper/fex/1474 new file mode 100644 index 000000000..7b3e70404 --- /dev/null +++ b/results/scraper/fex/1474 @@ -0,0 +1,2 @@ +Support personality emulation +Changes some edge case behaviour and what uname syscalls return. \ No newline at end of file diff --git a/results/scraper/fex/1475 b/results/scraper/fex/1475 new file mode 100644 index 000000000..d79e9fadb --- /dev/null +++ b/results/scraper/fex/1475 @@ -0,0 +1,3 @@ +Stop hardcoding squashfuse path +Currently we hardcode /usr/bin/squashfuse which isn't correct on all systems. +Use /bin/sh to search for squashfuse and execute it through that instead. \ No newline at end of file diff --git a/results/scraper/fex/1483 b/results/scraper/fex/1483 new file mode 100644 index 000000000..b11172d45 --- /dev/null +++ b/results/scraper/fex/1483 @@ -0,0 +1,31 @@ +With Fortification enabled when compiling we crash +``` +*** buffer overflow detected ***: terminated + +Program received signal SIGABRT, Aborted. +__pthread_kill_implementation (threadid=281474842431504, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 +44 pthread_kill.c: No such file or directory. +(gdb) bt +#0 __pthread_kill_implementation (threadid=281474842431504, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 +#1 0x0000fffff7bb7114 in __pthread_kill_internal (signo=<optimized out>, threadid=<optimized out>) at pthread_kill.c:80 +#2 0x0000fffff7b71f7c in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#3 0x0000fffff7b5ed30 in __GI_abort () at abort.c:79 +#4 0x0000fffff7bab078 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0xfffff7c8b470 "*** %s ***: terminated\n") + at ../sysdeps/posix/libc_fatal.c:155 +#5 0x0000fffff7c2d248 in __GI___fortify_fail (msg=msg@entry=0xfffff7c8b408 "buffer overflow detected") at fortify_fail.c:26 +#6 0x0000fffff7c2b984 in __GI___chk_fail () at chk_fail.c:28 +#7 0x0000fffff7c2b078 in __memcpy_chk (dstpp=<optimized out>, srcpp=<optimized out>, len=<optimized out>, dstlen=<optimized out>) + at memcpy_chk.c:28 +#8 0x0000aaaaaacbb704 in ?? () +#9 0x0000aaaaaacbd4b8 in ?? () +#10 0x0000aaaaaacb4908 in ?? () +#11 0x0000aaaaaacb2298 in ?? () +#12 0x0000aaaaaab1a11c in ?? () +#13 0x0000fffff7b5effc in __libc_start_call_main (main=main@entry=0xaaaaaab17498, argc=argc@entry=2, argv=argv@entry=0xfffffffff078) + at ../sysdeps/nptl/libc_start_call_main.h:58 +#14 0x0000fffff7b5f0c8 in __libc_start_main_impl (main=0xaaaaaab17498, argc=2, argv=0xfffffffff078, init=<optimized out>, + fini=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:409 +#15 0x0000aaaaaab171b0 in ?? () +``` + +Found from trying to run a PPA executable. \ No newline at end of file diff --git a/results/scraper/fex/1484 b/results/scraper/fex/1484 new file mode 100644 index 000000000..63ed071c5 --- /dev/null +++ b/results/scraper/fex/1484 @@ -0,0 +1,4 @@ +Update site w/ Getting started info + maybe CTA +Should point to https://wiki.fex-emu.com/index.php/QuickStartGuide + +Possibly update the theming a bit now that we have more content \ No newline at end of file diff --git a/results/scraper/fex/1496 b/results/scraper/fex/1496 new file mode 100644 index 000000000..d7824923c --- /dev/null +++ b/results/scraper/fex/1496 @@ -0,0 +1,2 @@ +FEXLogServer duplicates messages +Definitely a bit confusing when you're getting duplicated messages. \ No newline at end of file diff --git a/results/scraper/fex/1498 b/results/scraper/fex/1498 new file mode 100644 index 000000000..7b1f1e477 --- /dev/null +++ b/results/scraper/fex/1498 @@ -0,0 +1,3 @@ +FEXRootFSFetcher: Check if curl is installed +Currently we silently show bad results if curl isn't installed. +Check if it is installed and ask if you want to install it at the start. \ No newline at end of file diff --git a/results/scraper/fex/1505 b/results/scraper/fex/1505 new file mode 100644 index 000000000..e028f4112 --- /dev/null +++ b/results/scraper/fex/1505 @@ -0,0 +1,13 @@ +Implement libc thunk library +Thunking libc itself has the potential to make thunking other libraries significantly more robust by making various workarounds unnecessary (see #1208). Here's an (incomplete) list of nontrivial things that need to be tackled: + +* Program startup (`__libc_start_main`) +* `printf`-like functions (including fprintf, sprintf, snprintf, vprintf, ...) +* Functions with function pointer arguments (`qsort`) +* Data symbol handling: + * `errno` + * getopt: `optarg`/`optind`/`opterr`/`optopt` +* Struct repacking: + * Repacking of data in parameter structs that have different layouts across architectures (e.g. `stat`) + * Repacking for arguments passed to callbacks +* `__lxstat`/`__fxstat`/...: Data layout of parameter struct is determined by a version field diff --git a/results/scraper/fex/1508 b/results/scraper/fex/1508 new file mode 100644 index 000000000..3db397a34 --- /dev/null +++ b/results/scraper/fex/1508 @@ -0,0 +1,4 @@ +IR: ConstProp potentially incorrect mask +https://github.com/FEX-Emu/FEX/blob/main/External/FEXCore/Source/Interface/IR/Passes/ConstProp.cpp#L358 + +This mask value is set but never used. Looks like it should be used in place of `imm` on line `auto newArg = RemoveUselessMasking(IREmit, IROp->Args[i], imm);` but needs to be investigated. \ No newline at end of file diff --git a/results/scraper/fex/1511 b/results/scraper/fex/1511 new file mode 100644 index 000000000..fbee94a2f --- /dev/null +++ b/results/scraper/fex/1511 @@ -0,0 +1,26 @@ +IREmitter can't fail gracefully on large code blocks +If a code block overruns the 16MB(8MB times two) of temporary IR space we allocate per thread then FEX throws an assert and doesn't fallback gracefully. + +Investigate how we can fail gracefully. +Reject superblock and force upper limit on superblock size? +Expand the working IR size? + +16MB is fairly large already and if we supported resizing the temp space then this could be quite a bit nicer on memory consumption. +8MB goes to OrderedNode tracking, which gives 524288 possible IR ops. +The other 8MB goes to the OpData tracking, which obviously can't get anywhere near that 524k number. + +Simple asm test to trigger this case. Make sure to set blocksize to -1 to allow infinite block size. +```asm +%ifdef CONFIG +{ +} +%endif + +mov eax, 0 + +%rep 65537 +and eax, 0 +%endrep + +hlt +``` \ No newline at end of file diff --git a/results/scraper/fex/1514 b/results/scraper/fex/1514 new file mode 100644 index 000000000..fb17b4a62 --- /dev/null +++ b/results/scraper/fex/1514 @@ -0,0 +1,4 @@ +Implement custom std::unique_ptr to remove offsetof warnings. +Latest C++ container objects are all becoming non standard layout and using offsetof with classes/structs that contain them is undefined behaviour. + +It's well defined that it basically works but this is the only way to get rid of the warnings without rearchitecting a disgusting amount of context access code. \ No newline at end of file diff --git a/results/scraper/fex/1517 b/results/scraper/fex/1517 new file mode 100644 index 000000000..f60088f60 --- /dev/null +++ b/results/scraper/fex/1517 @@ -0,0 +1,2 @@ +SIGSEGV in Frontend when running wine + Multiblock +Running `wine notepad.exe` on an AArch64 host attempts to load from address `0xffffffffff470dc0` causing a SIGSEGV. Possible unintentional sign extension from `ff470dc0`. \ No newline at end of file diff --git a/results/scraper/fex/1521 b/results/scraper/fex/1521 new file mode 100644 index 000000000..94e74ab16 --- /dev/null +++ b/results/scraper/fex/1521 @@ -0,0 +1,13 @@ +Baba is you: Throws a bunch of LUA errors +**What Game** +Baba is You +https://store.steampowered.com/app/736260/Baba_Is_You/ + +**Describe the bug** +On boot up it opens a bunch of zenity windows and doesn't boot + +**To Reproduce** +Just launch the game + +**Expected behavior** +Not to do this diff --git a/results/scraper/fex/1524 b/results/scraper/fex/1524 new file mode 100644 index 000000000..2de9cd6cc --- /dev/null +++ b/results/scraper/fex/1524 @@ -0,0 +1,17 @@ +Super Meat Boy: Title screen no longer screams "SUPER MEAT BOY" at you +**What Game** +Super Meat boy +https://store.steampowered.com/app/40800/Super_Meat_Boy/ + +**Describe the bug** +The title screen is supposed to scream "Super meat boy" at you but instead it just lowers the volume. +This is a regression + +**To Reproduce** +Steps to reproduce the behavior: +1. Boot the game +2. Continue to the second screen +3. Not get yelled at by the game + +**Expected behavior** +Expect to get yelled at by the game diff --git a/results/scraper/fex/1525 b/results/scraper/fex/1525 new file mode 100644 index 000000000..ecbc81da4 --- /dev/null +++ b/results/scraper/fex/1525 @@ -0,0 +1,3 @@ +FEXRootFSFetcher: Check for working squashfuse +If squashfuse isn't installed or able to be executed. Then remove the "As-Is" Option with a warning and only allow extraction or exiting. +Setting the sqsh file as rootfs obviously won't work so don't let it get configured to be used. \ No newline at end of file diff --git a/results/scraper/fex/1526 b/results/scraper/fex/1526 new file mode 100644 index 000000000..2825ea234 --- /dev/null +++ b/results/scraper/fex/1526 @@ -0,0 +1,3 @@ +FEXRootFSFetcher: Check for working unsquashfs +Check that unsquashfs is installed and also make sure it supports zstd. +Remove the option to extract with a warning to let the user know it couldn't be extracted. \ No newline at end of file diff --git a/results/scraper/fex/1527 b/results/scraper/fex/1527 new file mode 100644 index 000000000..11a48f1a5 --- /dev/null +++ b/results/scraper/fex/1527 @@ -0,0 +1,3 @@ +FEXRootFSFetcher: On failure to download image, ask for retry. +Currently if the image fails to download then it'll return an error but then continue, asking if you want to extract or use as-is. +Handle this edge case and ask the user if they want to retry or cancel and also not continue. \ No newline at end of file diff --git a/results/scraper/fex/1528 b/results/scraper/fex/1528 new file mode 100644 index 000000000..5889e51d0 --- /dev/null +++ b/results/scraper/fex/1528 @@ -0,0 +1,6 @@ +Raspberry Pi ::::: I Cant Install Any Packages After Install RootFS +After Installed The RootFS The Sudo Isnt Work So No Admin Inside And No Package To Installed It! +I Try With ArchLinux, There No Networking, So, Always NOT Packages!! + +On My Raspberry Pi 400 +Raspberry Pi OS Bulleyes 64 Bit. \ No newline at end of file diff --git a/results/scraper/fex/1529 b/results/scraper/fex/1529 new file mode 100644 index 000000000..f91be0ed7 --- /dev/null +++ b/results/scraper/fex/1529 @@ -0,0 +1,39 @@ +Half-Life 2: Issues that have cropped up +**What Game** +Half-Life 2. Probably also other Source engine games +https://store.steampowered.com/app/220/HalfLife_2/ + +**Describe the bug** +Various bugs. +Camera doesn't rotate a full 360 degrees (tracked in issue #1220) +GMan during intro cinematic has vertex seams on the side of their face. + +Scripted AI characters walk backwards (Barney during opening scene when walking towards the torture room) + +Other characters having sparkles on vertex edges. Could be seams as well? + +**To Reproduce** +Steps to reproduce the behavior: +1. Start up Half-Life 2 +2. Sit through opening cinematic and look at GMan intently +3. Walk through the hallways until you reach the scene with Barney walking towards a room. See the backwards moon walking and sometimes spinning + +**Expected behavior** +None of that + +**System information:** + - OS: Ubuntu 21.10 + - CPU/SoC: Happens on both Snapdragon 888 and AMD host systems + - Video driver version: Mesa 22.0 devel or Mesa 21.3-rc + - RootFS used: Ubuntu 21.10 Official Rootfs + - FEX version: FEX-2201-49-gf41cd8de + - Thunks Enabled: No + +**Additional context** + - Is this an x86 or x86-64 game: x86 + - Does this reproduce on x86-64 host with FEX: Yes + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: No + +Add any other context about the problem here. +Seems to be CPU Emulation related. \ No newline at end of file diff --git a/results/scraper/fex/1532 b/results/scraper/fex/1532 new file mode 100644 index 000000000..b59079322 --- /dev/null +++ b/results/scraper/fex/1532 @@ -0,0 +1,12 @@ +32-bit socket ioctls aren't interpreted correctly. +We don't currently capture socket ioctls and just pass them through. +This causes a few socket based ioctl commands to not be correct. + +* SIOCGSTAMP_OLD +* SIOCGSTAMPNS_OLD +* SIOCGIFPFLAGS +* SIOCSIFFLAGS +* SIOCWANDEV +* Any other ioctl that returns `struct ifreq` + * https://man7.org/linux/man-pages/man7/netdevice.7.html +* Maybe more that I missed. \ No newline at end of file diff --git a/results/scraper/fex/1535 b/results/scraper/fex/1535 new file mode 100644 index 000000000..c1f26903a --- /dev/null +++ b/results/scraper/fex/1535 @@ -0,0 +1,32 @@ +Dead Island Definitive Edition: White screen on Snapdragon +**What Game** +Dead Island Definitive Edition +https://store.steampowered.com/app/383150/Dead_Island_Definitive_Edition/ + +**Describe the bug** +When booting the game, it's just a white screen. + +**To Reproduce** +Steps to reproduce the behavior: +1. Launch the game + +**Expected behavior** +Not a white screen + +**System information:** + - OS: Ubuntu 21.10 + - CPU/SoC: Snapdragon 888 + - Video driver version: OpenGL ES 3.2 Mesa 21.3.0-rc2 (git-8c4d7c35ed) + - RootFS used: Ubuntu 21.10 Official Rootfs (With mesa modifications) + - FEX version: FEX-2201-57-g9c8642e0 + - Thunks Enabled: No + +**Additional context** + - Is this an x86 or x86-64 game: x86-64 + - Does this reproduce on x86-64 host with FEX: No + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: Unknown + - If Yes, What is your Vulkan driver: + +**Add any other context about the problem here.** +Might be a video driver problem. Not sure yet. \ No newline at end of file diff --git a/results/scraper/fex/1537 b/results/scraper/fex/1537 new file mode 100644 index 000000000..ee258ba4d --- /dev/null +++ b/results/scraper/fex/1537 @@ -0,0 +1,6 @@ +FREM/FREM1: Support partial remainder +Currently both of these instructions calculate a full remainder. +There could be games that rely on the partial remainder behaviour of these instructions. +In particular the partial remainder is calculated if the exponent difference between the two values is greater than 63. + +These are some wacking huge numbers at that point so it ends up being unlikely but still needs to be supported. \ No newline at end of file diff --git a/results/scraper/fex/1538 b/results/scraper/fex/1538 new file mode 100644 index 000000000..b6b03202e --- /dev/null +++ b/results/scraper/fex/1538 @@ -0,0 +1,5 @@ +FPREM/FPREM1: Support rounding mode differences between these instructions +FPREM1 follows IEEE remainder while FPREM does not. +We should support the differences between these two instructions. Currently they map to the same instruction implementation. + +In particular: FPREM always truncates the quotient towards zero while FPREM1 rounds towards nearest. \ No newline at end of file diff --git a/results/scraper/fex/1545 b/results/scraper/fex/1545 new file mode 100644 index 000000000..9ae04abe1 --- /dev/null +++ b/results/scraper/fex/1545 @@ -0,0 +1,55 @@ +Osmos: 32bit "Instawin" (Motes not spawning) +**What Game** +Osmos + +Steam: https://store.steampowered.com/app/29180/Osmos/ (only contains 32bit version) +Demo: http://www.hemispheregames.com/latest_osmos_demo_linux_deb (contains both 32bit and 64bit versions, but has broken font) + +**Describe the bug** +The 64bit version of the game works fine, might actually be flawless. + +But the 32bit version has some really weird issues. When a level initialises, none of the motes appear, giving you just a blank background. + +Advancing though any tutorial with space and then clicking will cause the game to check win conditions, and depending on the level, you might win or lose. + +Resizing the window (or switching between fullscreen/windowed mode) causes all the motes to spawn, and it becomes possible to complete the level, at which point you need to resize again to spawn the motes. + +**To Reproduce** +Steps to reproduce the behavior: +1. Launch the game. +2. Open the first level +3. Press Space when prompted to dismiss quote +4. See error + +**Expected behavior** +A clear and concise description of what you expected to happen. + +**Screenshots and Video** + +Expected result: + + + +Result with 32bit binary: + + +Dismissing the rest of the tutroal text and clicking presents this win screen: + + + +**System information:** + - OS: Arch Linux Arm + - CPU/SoC: Apple M1X + - Video driver version: both llvmpipe and virgil + - RootFS used: Ubuntu 21.10 Official Rootfs + - FEX version: FEX-2201-80-g334a8ef8 + - Thunks Enabled: [Yes/No] + +**Additional context** + - Is this an x86 or x86-64 game: Both, but only x86 is broken. + - Does this reproduce on x86-64 host with FEX: Yes + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: No + - If Yes, What is your Vulkan driver: + +Note: The demo version of Osmos from their website ships with a broken font that might cause issues depending on the rootfs version. Symptoms include "log message about font issue, some menu text not rendering, clicking not working". Replacing it with a good version of the font (I copied it from the steam version) fixes the issues. diff --git a/results/scraper/fex/1556 b/results/scraper/fex/1556 new file mode 100644 index 000000000..fecee485f --- /dev/null +++ b/results/scraper/fex/1556 @@ -0,0 +1,5 @@ +Stop using MAP_GROWSDOWN +Due to how virtual address range growing works on Linux. We are leaking memory if a thread /ever/ manages to grow the stack. +This is due our munmap tracking never getting notified of the new address range on grow, thus when we munmap, we will only munmap the ORIGINAL mapping. Not the new pages that grew. Leaving stale pages around. + +We either need to switch to manual page growing in userspace, or on every munmap of a MAP_GROWS region, we need to check `/proc/self/maps` to get the real range. \ No newline at end of file diff --git a/results/scraper/fex/1557 b/results/scraper/fex/1557 new file mode 100644 index 000000000..3661e91c7 --- /dev/null +++ b/results/scraper/fex/1557 @@ -0,0 +1,6 @@ +Minor installation issue using installFEX.py and FEXRootFSFetcher +Hi, I'm new to use FEX and I installed it yesterday on proot Ubuntu on Termux. + +The `installFEX.py` in Ubuntu 21.10 KDE Konsole proot on Termux doesn't work as expected. `installFex.py` would skip user input of `FEXRootFSFetcher` and show `Unknown response. Assuming no` right away. + +Also, `FEXRootFSFetcher` downloading breaks easily. If an incomplete file is present, the fetcher fail always attempting redownload. Eventually I have to go into the folder and use `wget`. But http download breaks often and I tried around 10 times before successful yesterday. \ No newline at end of file diff --git a/results/scraper/fex/1559 b/results/scraper/fex/1559 new file mode 100644 index 000000000..b34572536 --- /dev/null +++ b/results/scraper/fex/1559 @@ -0,0 +1,43 @@ +Warning/[DEBUG] on proot (Termux) floods normal terminal output +After Sonicadvance1 downgrade #1389 from fatal to warning, the warning below shows up many times as a program runs. Is there any way to turn off such warning? This warning is annoying and floods normal output. Thanks! + +``` +[DEBUG] *** 00200000-00201000 r--p 00000000 fd:0a 1197177 /data/data/com.termux/files/usr/libexec/proot/loader +[DEBUG] 2000000000-2000001000 r-xp 00001000 fd:0a 1197177 /data/data/com.termux/files/usr/libexec/proot/loader +[DEBUG] 2000001000-2000002000 r--p 00001000 fd:0a 1197177 /data/data/com.termux/files/usr/libexec/proot/loader +[DEBUG] 3000000000-3000060000 r--p 00000000 fd:0a 1016886 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/bin/.l2s.FEXLoader0001.0002 +[DEBUG] 300006f000-3000294000 r-xp 0005f000 fd:0a 1016886 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/bin/.l2s.FEXLoader0001.0002 +[DEBUG] 30002a3000-30002cc000 r--p 00283000 fd:0a 1016886 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/bin/.l2s.FEXLoader0001.0002 +[DEBUG] 30002db000-30002dd000 rw-p 002ab000 fd:0a 1016886 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/bin/.l2s.FEXLoader0001.0002 +[DEBUG] 30002dd000-3000626000 rw-p 00000000 00:00 0 +[DEBUG] 3f00000000-3f00025000 r-xp 00000000 fd:0a 960398 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 +[DEBUG] 3f00034000-3f00036000 r--p 00024000 fd:0a 960398 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 +[DEBUG] 3f00036000-3f00038000 rw-p 00026000 fd:0a 960398 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 +[DEBUG] 7f29200000-7f29646000 rw-p 00000000 00:00 0 +[DEBUG] 7f29646000-7f29800000 ---p 00000000 00:00 0 +[DEBUG] 7f29800000-7f29a00000 rw-p 00000000 00:00 0 +[DEBUG] 7f29b4a000-7f29b52000 rw-p 00000000 00:00 0 +[DEBUG] 7f29b52000-7f29cdb000 r-xp 00000000 fd:0a 960939 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libc.so.6 +[DEBUG] 7f29cdb000-7f29cea000 ---p 00189000 fd:0a 960939 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libc.so.6 +[DEBUG] 7f29cea000-7f29ced000 r--p 00188000 fd:0a 960939 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libc.so.6 +[DEBUG] 7f29ced000-7f29cf0000 rw-p 0018b000 fd:0a 960939 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libc.so.6 +[DEBUG] 7f29cf0000-7f29cfc000 rw-p 00000000 00:00 0 +[DEBUG] 7f29cfc000-7f29d0f000 r-xp 00000000 fd:0a 961703 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libgcc_s.so.1 +[DEBUG] 7f29d0f000-7f29d1e000 ---p 00013000 fd:0a 961703 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libgcc_s.so.1 +[DEBUG] 7f29d1e000-7f29d1f000 r--p 00012000 fd:0a 961703 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libgcc_s.so.1 +[DEBUG] 7f29d1f000-7f29d20000 rw-p 00013000 fd:0a 961703 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libgcc_s.so.1 +[DEBUG] 7f29d20000-7f29da4000 r-xp 00000000 fd:0a 961774 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libm.so.6 +[DEBUG] 7f29da4000-7f29db3000 ---p 00084000 fd:0a 961774 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libm.so.6 +[DEBUG] 7f29db3000-7f29db4000 r--p 00083000 fd:0a 961774 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libm.so.6 +[DEBUG] 7f29db4000-7f29db5000 rw-p 00084000 fd:0a 961774 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libm.so.6 +[DEBUG] 7f29db5000-7f29db7000 rw-p 00000000 00:00 0 +[DEBUG] 7f29db7000-7f29fb4000 r-xp 00000000 fd:0a 961835 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.29 +[DEBUG] 7f29fb4000-7f29fc4000 ---p 001fd000 fd:0a 961835 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.29 +[DEBUG] 7f29fc4000-7f29fcf000 r--p 001fd000 fd:0a 961835 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.29 +[DEBUG] 7f29fcf000-7f29fd2000 rw-p 00208000 fd:0a 961835 /data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/ubuntu/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.29 +[DEBUG] 7f29fd2000-7f29fd5000 rw-p 00000000 00:00 0 +[DEBUG] 7f29ff6000-7f29ff7000 r--p 00000000 00:00 0 [vvar] +[DEBUG] 7f29ff7000-7f29ff8000 r-xp 00000000 00:00 0 [vdso] +[DEBUG] 7fecb08000-7fecb2a000 rw-p 00000000 00:00 0 [stack] +[DEBUG] [WARNING] FEX mapped to lower 32bits! 32-bit applications may have issues! +``` \ No newline at end of file diff --git a/results/scraper/fex/1560 b/results/scraper/fex/1560 new file mode 100644 index 000000000..5c5e4ab2c --- /dev/null +++ b/results/scraper/fex/1560 @@ -0,0 +1,37 @@ +Wine on proot (Termux): err:winediag:nodrv_CreateWindow +Thanks a lot for making this exciting x86 emulation project!! + +I tried to `wine winecfg` in FEXBash (wine-5.0 comes with RootFS Ubuntu 21.10), it does place files in ~/.wine but it doesn't show any GUI window, neither `wine64` + +Besides, Wine-7.0 from playonlinux works well with box86 on proot Termux, [LF2](https://lf2.net/) 1.9c playable smoothly. I would like to try wine-7.0 but I don't know how to manage RootFS with host FS in proot (Termux), as mentioned in another Github issue. + +More details for my setup: +> OS: proot Ubuntu 21.10, on Termux +> Display: software Mesa, KDE, Xvnc/TigerVNC, Android Desktop Mode + +Error log is below. Can't provide a full log due to #1559 (too many unrelated warnings printed). +I have GTK3 (i386 & amd64) and GTK2 (i386 & amd64) installed but CreateWindow. So what library do I miss or what else do I need? Thanks a lot!! +``` +000b:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. +000b:err:winediag:nodrv_CreateWindow The explorer process failed to start. +0010:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. +0010:err:winediag:nodrv_CreateWindow The explorer process failed to start. +0012:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. +0012:err:winediag:nodrv_CreateWindow The explorer process failed to start. +0012:err:ole:apartment_createwindowifneeded CreateWindow failed with error 183 +0012:err:ole:apartment_createwindowifneeded CreateWindow failed with error 0 +0012:err:ole:marshal_object couldn't get IPSFactory buffer for interface {00000131-0000-0000-c000-000000000046} +0012:err:ole:apartment_createwindowifneeded CreateWindow failed with error 14007 +0012:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hres=0x800736b7 +0012:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, 800736b7 +0012:err:ole:get_local_server_stream Failed: 800736b7 +0014:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. +0014:err:winediag:nodrv_CreateWindow The explorer process failed to start. +0014:err:ole:apartment_createwindowifneeded CreateWindow failed with error 0 +0014:err:ole:apartment_createwindowifneeded CreateWindow failed with error 0 +0014:err:ole:marshal_object couldn't get IPSFactory buffer for interface {00000131-0000-0000-c000-000000000046} +0014:err:ole:apartment_createwindowifneeded CreateWindow failed with error 14007 +0014:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hres=0x800736b7 +0014:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, 800736b7 +0014:err:ole:get_local_server_stream Failed: 800736b7 +``` \ No newline at end of file diff --git a/results/scraper/fex/1561 b/results/scraper/fex/1561 new file mode 100644 index 000000000..16387880e --- /dev/null +++ b/results/scraper/fex/1561 @@ -0,0 +1,8 @@ +Trouble with RootFS package management on proot (Termux) +For proot on Termux (no root, based on a trimmed Linux kernel), it's rather difficult to manage packages in RootFS. Neither chroot (due to no root) nor fusermount (seems no kernel support on Android, or root required) would work. + +Lately I tried wine on FEX and installed wine 7.0 on host OS. But FEX seems to prefer RootFS files (wine-5.0 and libwine.so) over host OS files but I couldn't manage RootFS packages. Can I change its preference for host OS vs. RootFS? Or how could I manage (e.g. `apt`) or remove RootFS packages given chroot and fusermount not available? + +I would be grateful if you may provide more details on FEX mechanism, which I couldn't find from Wiki page. Why does FEX need RootFS when Ubuntu/Debian MultiAarch is there (won't it be good to, or can I, run FEX with only MultiArch and without RootFS, just like box86/box64)? What makes RootFS different from FS from a typical distro image or chroot FS (does RootFS replaces any Ubuntu files/libs with thunklibs)? + +Thanks a lot! \ No newline at end of file diff --git a/results/scraper/fex/1569 b/results/scraper/fex/1569 new file mode 100644 index 000000000..de9ec12f9 --- /dev/null +++ b/results/scraper/fex/1569 @@ -0,0 +1,3 @@ +Support building thunks with clang +Some platforms don't provide `x86_64-linux-gnu-g++` +We should be more flexible and allow building and linking with clang. \ No newline at end of file diff --git a/results/scraper/fex/1577 b/results/scraper/fex/1577 new file mode 100644 index 000000000..321363f4b --- /dev/null +++ b/results/scraper/fex/1577 @@ -0,0 +1,2 @@ +Graphical programs not launching on Switchroot Ubuntu (Updated) +I keep running into multiple build errors during the final stage of compilation. I'm on a fresh installation of Ubuntu 18.04 on my Nintendo Switch running Switchroot Linux. I installed dependencies as listed in the quick start guide (as well as some that weren't listed, such as `sudo apt install libstdc++-8-dev` to prevent the error message "#include <filesystem> : file or directory not found"). However, some build errors just won't go away. I'm not sure what my next steps should be, but I'll upload my build log below. I'd be happy to help any ways I can. \ No newline at end of file diff --git a/results/scraper/fex/1583 b/results/scraper/fex/1583 new file mode 100644 index 000000000..1ce6266b6 --- /dev/null +++ b/results/scraper/fex/1583 @@ -0,0 +1,2 @@ +Forcing color output breaks VSCode Linux integration +Add an option to the CMakeLists to disable colour output? \ No newline at end of file diff --git a/results/scraper/fex/1584 b/results/scraper/fex/1584 new file mode 100644 index 000000000..8c692c1f5 --- /dev/null +++ b/results/scraper/fex/1584 @@ -0,0 +1,2 @@ +FSCALE implementation incorrect +Host x87 gives 128 as result in D9_FD.asm, FEX gives 256. Investigation needed. \ No newline at end of file diff --git a/results/scraper/fex/1592 b/results/scraper/fex/1592 new file mode 100644 index 000000000..3529ea1cf --- /dev/null +++ b/results/scraper/fex/1592 @@ -0,0 +1,2 @@ +No uninstall with ninja +Wondering is there plans for a way to uninstall FEX from you system diff --git a/results/scraper/fex/1600 b/results/scraper/fex/1600 new file mode 100644 index 000000000..10e91965d --- /dev/null +++ b/results/scraper/fex/1600 @@ -0,0 +1,29 @@ +Aperture Desk Job: Crashes past loading screen +**What Game** +Aperture Desk Job +https://store.steampowered.com/app/1902490/Aperture_Desk_Job/ + +**Describe the bug** +Game crashes in the game's vulkan system + +**To Reproduce** +Steps to reproduce the behavior: +1. Run the game + +**Expected behavior** +Expect it to not crash + +**System information:** + - OS: Ubuntu 22.04 + - CPU/SoC: Radeon RX 5700, 2990WX + - Video driver version: Mesa 22.0 + - RootFS used: / + - FEX version: Main + - Thunks Enabled: No + +**Additional context** + - Is this an x86 or x86-64 game: x86-64 + - Does this reproduce on x86-64 host with FEX: Yes + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested on AArch64 + - Is this a Vulkan game: Yes + - If Yes, What is your Vulkan driver: Mesa 22.0 \ No newline at end of file diff --git a/results/scraper/fex/1602 b/results/scraper/fex/1602 new file mode 100644 index 000000000..4a9be5ba0 --- /dev/null +++ b/results/scraper/fex/1602 @@ -0,0 +1,3 @@ +ioctl emulation: missing DRM_IOCTL_MSM_SET_PARAM +Missing the ioctl wrapping for this. Freedreno uses this for perfetto system profiling of GPU data. +No emulation needed, just passthrough. \ No newline at end of file diff --git a/results/scraper/fex/1615 b/results/scraper/fex/1615 new file mode 100644 index 000000000..ce2858659 --- /dev/null +++ b/results/scraper/fex/1615 @@ -0,0 +1,7 @@ +What is the extra slot used for? (I.e. why not just `MAX_SIGNALS` elements?) +What is the extra slot used for? (I.e. why not just `MAX_SIGNALS` elements?) + +_Originally posted by @neobrain in https://github.com/FEX-Emu/FEX/pull/1613#discussion_r823493879_ + +This is an antipattern seen through our signal handling due to signals using 1 based indexing with 0 being special cased. +Resolve this pattern and come back to it. \ No newline at end of file diff --git a/results/scraper/fex/1618 b/results/scraper/fex/1618 new file mode 100644 index 000000000..6ed09fff6 --- /dev/null +++ b/results/scraper/fex/1618 @@ -0,0 +1,3 @@ +Bad pointer set +https://github.com/FEX-Emu/FEX/blob/23a1c64bf7a66508db529691bc07dfcba07d09ec/External/FEXCore/Source/Interface/Core/JIT/Arm64/JIT.cpp#L390 +This line pulling a pointer from Dispatcher before it is set. \ No newline at end of file diff --git a/results/scraper/fex/1619 b/results/scraper/fex/1619 new file mode 100644 index 000000000..bbaddc1f1 --- /dev/null +++ b/results/scraper/fex/1619 @@ -0,0 +1,10 @@ +Support Apple TSO mode enable bit +Once the kernel has some sort of interface for enabling this flag (prctl?, arch_prctl?) then wire this up. + +This should be as simple as changing the TSO IR ops to fall to the "non-atomic" variants and adding a flag to the code cache config. +M1/M1X is already significantly faster than Snapdragon even without this hardware feature enabled. So it would just be an improvement on already fast hardware. + +TODO: Is there a way to make non-coherent loadstores happen while this TSO flag is still enabled? Loading from our context, TLS, and stack accesses that we already convert to non-TSO for example. +Would need someone with hardware to test. Worst case we just eat the TSO cost always, which isn't terrible. + +TODO: Hopefully the kernel interface is per thread, so our helper threads don't pay the TSO cost, since they don't need it. \ No newline at end of file diff --git a/results/scraper/fex/1625 b/results/scraper/fex/1625 new file mode 100644 index 000000000..0b78135ab --- /dev/null +++ b/results/scraper/fex/1625 @@ -0,0 +1,15 @@ +Support IR and RAData thread pool allocation +Support allocating this out of a reuse pool. +This way threads that aren't actively compiling code aren't causing memory overhead. +Have them relinquish their resources to the pool after using them. If the all resources are consumed then allocate more objects in the pool. +Free pool resources in an LRU manner once they have reached some threshold. +This will reduce the memory usage overhead of FEX substantially. Currently our per thread memory allocations are quite heavy, so something like Steam consumes 1.3GB idling and half of that is due to IR/RAData staging buffers that aren't used since most threads are just sitting in pselect. + +Current known areas to throw in a pool: +* OpcodeDispatcher: 8MB + 8MB +* IRCompaction: 8MB + 8MB +* Frontend: Instruction decode buffer: 6.5MB (sizeof(DecodeInst) * 0x10000) (Set up with mmap so it doesn't use all the physical memory) +* RAData: A few dozen megabytes per thread? Will need to check again. + +For reference. Idling Steam has 39 threads (not including steamwebhelper) so even with the minimum of OpcodeDispatcher+IRCompaction being 32MB. That's still 1248MB burned to idling work. +Which holds true since the process is consuming >1.5GB idling at that point. \ No newline at end of file diff --git a/results/scraper/fex/1626 b/results/scraper/fex/1626 new file mode 100644 index 000000000..fe0aba588 --- /dev/null +++ b/results/scraper/fex/1626 @@ -0,0 +1,13 @@ +Classify unit tests with string feature requirements +Something in the config that we can query and gives a textual representation of what the runner (Host or FEX) needs to support to even try executing. Skip if it doesn't. +Something in the config section like: + +```json +%ifdef CONFIG +{ + "RegData": { + "XMM0": ["0x5152535455565758", "0x7172737475767778"] + }, + "Requires": ["SSE", "SSE2", "AVX"] +} +%endif``` \ No newline at end of file diff --git a/results/scraper/fex/1629 b/results/scraper/fex/1629 new file mode 100644 index 000000000..4cb3c45b4 --- /dev/null +++ b/results/scraper/fex/1629 @@ -0,0 +1,26 @@ +Error when linking +Hi, + +I just pulled the FEX sources and tried to build them, according to the instructions in https://github.com/FEX-Emu/FEX#quick-start-guide. + +The build gets me in the error listed below when linking UnitTestGenerator. I would appreciate some tips on getting past this. + +Some details: + +clang version 10.0.0-4ubuntu1 +Target: aarch64-unknown-linux-gnu +Linux version 5.10.87 +Description: Ubuntu 20.04.4 LTS + +Thanks, + +Julius + +**[243/324] Linking CXX executable Bin/UnitTestGenerator +FAILED: Bin/UnitTestGenerator +: && /usr/bin/clang++ -O3 -DNDEBUG -fomit-frame-pointer -flto=thin -fPIE -pie Source/Tests/CMakeFiles/UnitTestGenerator.dir/UnitTestGenerator.cpp.o -o Bin/U: +/usr/bin/ld: error: Failed to link module External/FEXCore/Source/libFEXCore.a.llvm.7437846.jemalloc.c: Expected at most one ThinLTO module per bitcode file +clang: error: linker command failed with exit code 1 (use -v to see invocation) +[248/324] Linking CXX shared library External/FEXCore/Source/libFEXCore.so +ninja: build stopped: subcommand failed.** + diff --git a/results/scraper/fex/1630 b/results/scraper/fex/1630 new file mode 100644 index 000000000..cb8ac9979 --- /dev/null +++ b/results/scraper/fex/1630 @@ -0,0 +1,3 @@ +Kega fusion fails to map memory +Looks like Kega Fusion does some allocating that breaks under FEX for some reason. +mmap return EINVAL and early exiting. Probably something simple. \ No newline at end of file diff --git a/results/scraper/fex/1631 b/results/scraper/fex/1631 new file mode 100644 index 000000000..823bf6b3a --- /dev/null +++ b/results/scraper/fex/1631 @@ -0,0 +1,2 @@ +ARMv8.5-RNG used even if not enabled by the kernel +In m1/parallels VM with ubuntu 5.4.0 fex generates `mrs x20,rndr` even though ARMv8.5-RNG is not supported by the kernel \ No newline at end of file diff --git a/results/scraper/fex/1636 b/results/scraper/fex/1636 new file mode 100644 index 000000000..72c376032 --- /dev/null +++ b/results/scraper/fex/1636 @@ -0,0 +1,2 @@ +FEX::HLE::MemAllocator returns -errno, code expects MAP_FAILED +I've run into this a few times where FEX::HLE::MemAllocator::mmap is used as a replacement for mmap, even though error checking needs to be different \ No newline at end of file diff --git a/results/scraper/fex/1637 b/results/scraper/fex/1637 new file mode 100644 index 000000000..4d9e5948c --- /dev/null +++ b/results/scraper/fex/1637 @@ -0,0 +1,2 @@ +Route all HLE/syscall guest mmap/munmap/mprotect through common wrappers +This is needed for SMC tracking to work correctly, as it needs to track all allocations \ No newline at end of file diff --git a/results/scraper/fex/1638 b/results/scraper/fex/1638 new file mode 100644 index 000000000..055e0312e --- /dev/null +++ b/results/scraper/fex/1638 @@ -0,0 +1,6 @@ +SMC/Mtrack: Add shm, mremap, madvise support +shmat, mremap are not tracked for smc. + +Tests: https://github.com/FEX-Emu/fex-assorted-tests-bins/blob/main/src/smc-2.cpp + +Looks like the shm size would have to be queried on map / unmap, similar to the tracking the 32-bit allocator does. \ No newline at end of file diff --git a/results/scraper/fex/1639 b/results/scraper/fex/1639 new file mode 100644 index 000000000..30cb7acd3 --- /dev/null +++ b/results/scraper/fex/1639 @@ -0,0 +1,5 @@ +SMC/Mtrack: Add mirrored memory support +Can be both in process and out of process, and both for shm and files + +In process test case: https://github.com/FEX-Emu/fex-assorted-tests-bins/blob/main/src/smc-shared.cpp +Out of process test case: https://github.com/FEX-Emu/fex-assorted-tests-bins/blob/main/src/smc-shared-2.cpp \ No newline at end of file diff --git a/results/scraper/fex/1642 b/results/scraper/fex/1642 new file mode 100644 index 000000000..a839e1e99 --- /dev/null +++ b/results/scraper/fex/1642 @@ -0,0 +1,8 @@ +How to compile in Termux (no proot) +Im trying to compile latest fex-emu on termux , but failed. + +Im not in proot, so it still on android. + +Is i need to proot/chroot first? + + diff --git a/results/scraper/fex/1646 b/results/scraper/fex/1646 new file mode 100644 index 000000000..04aa1311d --- /dev/null +++ b/results/scraper/fex/1646 @@ -0,0 +1,14 @@ +FEXLoader fails to run itself in ENABLE_X86_HOST_DEBUG +Not sure if this is an important case, but hit it when I was playing around with FEX: + +$ ~/FEX/Build/Bin/FEXLoader -- ~/FEX/Build/Bin/FEXLoader /usr/bin/zip +Illegal instruction (core dumped) + + + Build command: + CC=clang CXX=clang++ cmake -DENABLE_X86_HOST_DEBUG=True -DENABLE_LLD=True -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug -DENABLE_LTO=True -DBUILD_TESTS=False -G Ninja .. + +$ uname -a +Linux jvanderspek-lap 5.13.0-39-generic #44~20.04.1-Ubuntu SMP Thu Mar 24 16:43:35 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux + + diff --git a/results/scraper/fex/1647 b/results/scraper/fex/1647 new file mode 100644 index 000000000..bd9a45a62 --- /dev/null +++ b/results/scraper/fex/1647 @@ -0,0 +1,24 @@ +Inconsistency in RootFS handling between bare ELFs and shebangs +As mentioned on Discord the other day, there is an inconsistency in how the binary lookup in LinuxSyscalls is handled between actual ELF binaries and files with a shebang. + +For the `execve()`/… path, the RootFS path is only prepended to absolute paths if the file actually exists there: + +https://github.com/FEX-Emu/FEX/blob/8ad14728f6e4b5da4d1a42a38910785aa18802c7/Source/Tests/LinuxSyscalls/Syscalls.cpp#L122-L131 + +For actual ELF binaries, this is the only path involved. If that file starts with a shebang, however, the RootFS path is prepended unconditionally to the path specified in the shebang, no matter whether the file actually exists in the RootFS or not: + +https://github.com/FEX-Emu/FEX/blob/8ad14728f6e4b5da4d1a42a38910785aa18802c7/Source/Tests/LinuxSyscalls/Syscalls.cpp#L98-L103 + +(same in FEXLoader) + +This seems odd, and breaks use cases where most of the x86_64 files actually do exist on the host (with proper paths), and only few "emulated" binaries are to be read from the RootFS instead. + +Additionally, part of the shebang handling logic is duplicated between FEXLoader and LinuxSyscalls, which might sensibly be merged: + +https://github.com/FEX-Emu/FEX/blob/8ad14728f6e4b5da4d1a42a38910785aa18802c7/Source/Tests/FEXLoader.cpp#L125-L155 + +https://github.com/FEX-Emu/FEX/blob/8ad14728f6e4b5da4d1a42a38910785aa18802c7/Source/Tests/LinuxSyscalls/Syscalls.cpp#L74-L103 + +--- + +I was working on a fix for this, until @Sonicadvance1 pointed out that in situations where the RootFS isn't really necessary (e.g. when using Nix with binfmt_misc or similar, where binaries for both architectures exist side-by-side on the host and paths are properly set up for this), I might just as well disable the RootFS altogether. Still, it seems that the inconsistency here is unexpected behaviour – I am happy to finish this up and open a PR if desired. \ No newline at end of file diff --git a/results/scraper/fex/1648 b/results/scraper/fex/1648 new file mode 100644 index 000000000..6f1c0f6f8 --- /dev/null +++ b/results/scraper/fex/1648 @@ -0,0 +1,2 @@ +Docker for Building? +Is it possible to provide a Docker image with all the dependencies already installed, so people can build it? \ No newline at end of file diff --git a/results/scraper/fex/1650 b/results/scraper/fex/1650 new file mode 100644 index 000000000..fc89ef043 --- /dev/null +++ b/results/scraper/fex/1650 @@ -0,0 +1,12 @@ +[Apple M1/Asahi Linux] <jemalloc>: Unsupported system page size +Hello, I'm running into the following error when FEX is built and run on Asahi Linux: + +``` +<jemalloc>: Unsupported system page size +<jemalloc>: Unsupported system page size +<jemalloc>: Unsupported system page size +terminate called without an active exception +Aborted +``` + +Is there a know workaround or fix? \ No newline at end of file diff --git a/results/scraper/fex/1651 b/results/scraper/fex/1651 new file mode 100644 index 000000000..a82630d95 --- /dev/null +++ b/results/scraper/fex/1651 @@ -0,0 +1,7 @@ +FEXDriver --aotircapture hangs during IR writing +Ubuntu 20.04.4 LTS on i86 + +Command: FEX/Build/Bin/FEXLoader --aotircapture /usr/bin/zip +Runs the zip command, but hangs in the alignment loop at AOTIR.cpp, line 151. + +Is this a known issue? \ No newline at end of file diff --git a/results/scraper/fex/1654 b/results/scraper/fex/1654 new file mode 100644 index 000000000..54e6e9f2d --- /dev/null +++ b/results/scraper/fex/1654 @@ -0,0 +1,10 @@ +AOTIR: Deleting the RAData inappropriately +https://github.com/FEX-Emu/FEX/blob/42a632093545d0bf74bb1d87e285e58fa18d0aef/External/FEXCore/Source/Interface/IR/AOTIR.cpp#L353 + +This is allocated using using FEXCore::Allocator::malloc, then it tries to get freed with C++ delete. +https://github.com/FEX-Emu/FEX/blob/42a632093545d0bf74bb1d87e285e58fa18d0aef/External/FEXCore/Source/Interface/IR/Passes/RegisterAllocationPass.cpp#L156 + +This is why when allocating it we have it in a unique_ptr with a custom deleter, but the code is just wrong here. +`std::unique_ptr<IR::RegisterAllocationData, IR::RegisterAllocationDataDeleter> AllocData;` + +This causes LLVM asan to just immediately barf. \ No newline at end of file diff --git a/results/scraper/fex/1655 b/results/scraper/fex/1655 new file mode 100644 index 000000000..0d186361f --- /dev/null +++ b/results/scraper/fex/1655 @@ -0,0 +1,10 @@ +RA pass should use less memory +The register allocation pass uses a significant amount of memory . +This should be setup to use the thread pool allocator so threads can eventually relinquish ownership of their buffers. +This isn't a simple task because we are relying on some destructors to run at some points. + +The biggest contributor to memory usage is `std::vector<RegisterNode> Nodes{};` inside of RegisterGraph since we always allocate that to 8192 nodes per thread by default. Which makes it be 4MB per thread, expanding beyond that if the node count isn't enough. + +The second largest usage there is the RegisterGraph itself, which I believe is mostly from the RegisterSet but that would need to be checked on. + +These are all allocated without mmap, so it adds up quickly how much memory it uses. Especially when running something like Steam with a bunch of processes and threads. \ No newline at end of file diff --git a/results/scraper/fex/166 b/results/scraper/fex/166 new file mode 100644 index 000000000..bf3783c94 --- /dev/null +++ b/results/scraper/fex/166 @@ -0,0 +1,4 @@ +Fix static and EXEC executables +Somewhere along the line these were broken. Maybe when we switched to unified memory? +I wasn't really testing them to ensure they kept working, but we definitely need to keep them working. +I'll fix this. \ No newline at end of file diff --git a/results/scraper/fex/1660 b/results/scraper/fex/1660 new file mode 100644 index 000000000..9f036936c --- /dev/null +++ b/results/scraper/fex/1660 @@ -0,0 +1,4 @@ +MWAIT/MWAITX with WFE/WFET? +These can be implemented using the global exclusive monitor. + +WFET is quite new with ARMv8.7, WFE has been around for a while. \ No newline at end of file diff --git a/results/scraper/fex/1663 b/results/scraper/fex/1663 new file mode 100644 index 000000000..b0b9e689b --- /dev/null +++ b/results/scraper/fex/1663 @@ -0,0 +1,2 @@ +Emit FJCVTZS on ARMv8.3+ +For float -> 32-bit int overflow, `fjcvtzs` will produce a result of `0x80000000` matching X87 `fist` and SSE `CVTTSD2SI`. Easy accuracy win on ARMv8.3+ to replace `fcvtzs` with `fjcvtzs` \ No newline at end of file diff --git a/results/scraper/fex/1665 b/results/scraper/fex/1665 new file mode 100644 index 000000000..b08220ebb --- /dev/null +++ b/results/scraper/fex/1665 @@ -0,0 +1,2 @@ +F64: MXCSR and FCW round modes mixed +In implementing rounding in F64 mode for #1664, the states for MXCSR and FCW both set the host rounding mode, overwriting each other. This is visible to the guest through the possibility of incorrect rounding. These should be set independently. diff --git a/results/scraper/fex/1666 b/results/scraper/fex/1666 new file mode 100644 index 000000000..73a139beb --- /dev/null +++ b/results/scraper/fex/1666 @@ -0,0 +1,21 @@ +Deferred signals investigation +## Overview +This has interesting complications and can resolve unity problems. + +## Current high level idea + +Add a new config option or two that enables "deferred/safe signal handling" +- Introduce the concept of "exit points" in the JIT, places where we can handle state +- Sprinkle "exit points" around in blocks in such a way that there is a bounded time between them +- Modify signal setters to block all signals on signals entry +- Modify signal handlers to resume JIT execution up to the next "exit point", and then handle the signal +- Edge cases: signals on syscalls, signals in non-jit code +- Add a signal torture test or two to our tests + +## Other related ideas +- Add signal safe mode for all locks + +## Curent low level ideas for first implementation +- use `ldb/stb [ctx-1], #0` + a guard page before the context for low cost handling of "should we exit from exit point" checks + +(Description updated by @skmp) \ No newline at end of file diff --git a/results/scraper/fex/1667 b/results/scraper/fex/1667 new file mode 100644 index 000000000..da3695aa0 --- /dev/null +++ b/results/scraper/fex/1667 @@ -0,0 +1,2 @@ +Expose HT for SMT ARM CPUs +ARM is adding SMT to their CPUs. This is launching first with Cortex-A65AE, but we should be able to expose HT through their SMT parts. Just needs some CPUID stuff. \ No newline at end of file diff --git a/results/scraper/fex/1675 b/results/scraper/fex/1675 new file mode 100644 index 000000000..ee7bb2820 --- /dev/null +++ b/results/scraper/fex/1675 @@ -0,0 +1,4 @@ +Investigate moving LocalIRCache to LookupCache, Interpreter issues w/ Multi Threaded code invalidation +Follow up from #1670. + +This will also allow `Context::InvalidateGuestThreadCodeRange` to be moved to `LookupCache` \ No newline at end of file diff --git a/results/scraper/fex/1676 b/results/scraper/fex/1676 new file mode 100644 index 000000000..b034ac2fe --- /dev/null +++ b/results/scraper/fex/1676 @@ -0,0 +1,4 @@ +Add tests for Context-wide code invalidations +Follow up from #1670, #1558. + +Needs the to be part of #1558 or to be done after it, as there's no other way to test it \ No newline at end of file diff --git a/results/scraper/fex/1678 b/results/scraper/fex/1678 new file mode 100644 index 000000000..7c35c4c60 --- /dev/null +++ b/results/scraper/fex/1678 @@ -0,0 +1,15 @@ +Make object ownership, lifetime and non-nullable pointers more obvious +Follow up from #1671 from discussion with @neobrain + +> Better tracking allocation/free responsibilities, as well as nullable pointers would be an interesting code quality improvement. + +Myself I'm not much of a fan of C++ references, mostly because of the confusion they can create over what is a pointer and what is not, and I mostly use to rename locals in functions. The codebase mixes in pointers and references in arbitrary ways, which can create confusion. + +There's a couple of arguments for using more references, to communicate among other things +- non nullable uses +- pointer constness +- Allocation / Free semantics + +We could easily track these with some annotating templates, and avoid references, or we could go full in references and whatnot. + +Thoughts? diff --git a/results/scraper/fex/1679 b/results/scraper/fex/1679 new file mode 100644 index 000000000..80f3cba01 --- /dev/null +++ b/results/scraper/fex/1679 @@ -0,0 +1,4 @@ +Fully validate / handle highly contested multithreaded invalidations +Split off from #1671, which tries to be multi threading safe, but hasn't been fully vetted or verified that it always behaves correctly. + +This was out of scope for the initial SMC PR, and even though it has worked in my tests, it should be revisited. \ No newline at end of file diff --git a/results/scraper/fex/168 b/results/scraper/fex/168 new file mode 100644 index 000000000..7b1e2fdf8 --- /dev/null +++ b/results/scraper/fex/168 @@ -0,0 +1,5 @@ +Resolve paths passed to VFS/HLE to canonical +Find all VFS HLE routines, such as +EmulatedFDManager::OpenAt() and resolve path arguments to canonical form before using in map<path,fd> + +Currently only absolute paths that match perfectly will work. \ No newline at end of file diff --git a/results/scraper/fex/1680 b/results/scraper/fex/1680 new file mode 100644 index 000000000..59c95d83a --- /dev/null +++ b/results/scraper/fex/1680 @@ -0,0 +1,2 @@ +Implement VMA merging for our memtrack code +Follow up from #1558, after new maps, or permission changes VMAs might be mergeable. \ No newline at end of file diff --git a/results/scraper/fex/1681 b/results/scraper/fex/1681 new file mode 100644 index 000000000..8fd62462a --- /dev/null +++ b/results/scraper/fex/1681 @@ -0,0 +1,8 @@ +std::shared_mutexes can't be safelly locked across forks +I run into this as part of #1558. + +If they are locked before fork, then after fork they may or may not lockup on next lock, semi-randomly. + +Looks like we need to roll our own `shared_mutex` implementation. + +In general in need a gameplan for fork safety of FEXCore / Syscalls code \ No newline at end of file diff --git a/results/scraper/fex/1687 b/results/scraper/fex/1687 new file mode 100644 index 000000000..cba9917de --- /dev/null +++ b/results/scraper/fex/1687 @@ -0,0 +1,12 @@ +shared_mutex with unique lock priority +Having a shared lock where unique locks take priority would be beneficial. +std::shared_mutex gives shared locks priority when a shared lock is already held. + +With a new lock with unique priority it should have the properties: + +1. When a shared lock is already held and then a unique lock is attempting to be made + - Subsequent `try_lock_shared` should immediately return false even though unique_lock isn't held yet + - Subsequent `lock_shared` should block until unique lock is granted and relinquished + - If a subsequent unique lock is pending while a unique lock is already held then a shared lock shouldn't be able to win the contention. + +Might be worth using `WFE/WFET` for faster userspace checking of lock if it is expected to not be contended for too long. \ No newline at end of file diff --git a/results/scraper/fex/169 b/results/scraper/fex/169 new file mode 100644 index 000000000..e6ce39314 --- /dev/null +++ b/results/scraper/fex/169 @@ -0,0 +1,5 @@ +ELF Handling code relies on section headers +Nearly all of the elf processing uses section headers, which are very convenient to work with as there is much more information and split better. + +The problem is section headers can be stripped off, while it's rare it's perfectly valid and only program headers are needed to build the process image. + diff --git a/results/scraper/fex/1692 b/results/scraper/fex/1692 new file mode 100644 index 000000000..3fec0154a --- /dev/null +++ b/results/scraper/fex/1692 @@ -0,0 +1,2 @@ +Add -fwrapv to the compiler options +Guarantees that singed overflows are defined as 2's overflows, instead of undefined \ No newline at end of file diff --git a/results/scraper/fex/1695 b/results/scraper/fex/1695 new file mode 100644 index 000000000..30cb5c9cd --- /dev/null +++ b/results/scraper/fex/1695 @@ -0,0 +1,5 @@ +Consume less memory with relocations +https://github.com/FEX-Emu/FEX/blob/b5ae9e4c976fd2c542502e48c3e734c7bdd0e089/External/FEXCore/Source/Interface/Core/ObjectCache/Relocations.h#L72 + +Currently relocations use a union which causes them all to be 48 bytes in size. +We can save a bit of allocation overhead by not using a union. Thunks are significantly less common than the other relocations, which means that 16 (or 10 when packed) ends up being quite a bit smaller than 48. \ No newline at end of file diff --git a/results/scraper/fex/1696 b/results/scraper/fex/1696 new file mode 100644 index 000000000..8c7c11ca6 --- /dev/null +++ b/results/scraper/fex/1696 @@ -0,0 +1,9 @@ +Define standarised TODO markers +We can define +``` +TODO_ISSUE(issuenumber, username, comment) +TODO_ISSUE(issuenumber, comment) +TODO(username,comment) +TODO(comment) +``` +For a more structured way of handling TODOs \ No newline at end of file diff --git a/results/scraper/fex/1698 b/results/scraper/fex/1698 new file mode 100644 index 000000000..192602f0a --- /dev/null +++ b/results/scraper/fex/1698 @@ -0,0 +1,2 @@ +Test write only mappings with SMC protection +Follow up from #1558 \ No newline at end of file diff --git a/results/scraper/fex/1701 b/results/scraper/fex/1701 new file mode 100644 index 000000000..0b8705e36 --- /dev/null +++ b/results/scraper/fex/1701 @@ -0,0 +1,15 @@ +Write up a CONTRIBUTING.MD +Would be nice to define a few things + +Ideas +- Make note of code of conduct, etc boilerplate +- Setup some coordination and communication guidelines (eg, to make sure work is aligned/doesn't conflict with the project goals / timeline / current work) +- Setup Coding guidelines (naming, namespacing, style, formating, documentation, tabs, spell checking, linting, etc) +- Codify our review process +- Other things? + +This will allow us to be both more consistent, more open to contributions, and also a place that we can catch up with changes done to procedures/expectations. + +Random sample from the internet: https://gist.github.com/PurpleBooth/b24679402957c63ec426 + +Thoughts? \ No newline at end of file diff --git a/results/scraper/fex/1708 b/results/scraper/fex/1708 new file mode 100644 index 000000000..941829297 --- /dev/null +++ b/results/scraper/fex/1708 @@ -0,0 +1,155 @@ +AArch64 Virtual Address space problems. +AArch64 ships with up to a 48-bit Virtual address space (Or 52-bit with LPA2 but due to how that is implemented doesn't matter). +This is contrary to x86-64 which only gives userspace a 47-bit VA. + +This causes a problem where on running an x86-64 application under FEX, we need to reserve the entire 48-bit VA space to ensure the guest application never allocates memory in that space. See #1346 for real application bugs here. This means FEX always has 128TB of VA space allocated at start up. + +In addition to this, 32-bit applications only exist in the lower 32-bits of VA. This causes us to need to reserve all 64-bit VA space. +Same problems here but now we take even longer and reserve 256GB of VA space (Subtract 4GB). + +This means we have two different problem spaces to tackle immediately. +In addition to this, we have Thunks which complicate this matter. + +Syscalls that allocate memory: +- mmap, mmap2(Doesn't exist on ARM), mremap, shmat, ioctl + +**For people coming in from external projects** +``` +What is FEX-Emu? +FEX is a AArch64 ONLY userspace emulator of 32-bit x86 and x86-64. +32-bit x86 runs inside of an AArch64 container, which future proofs FEX for when ARM CPUs lose support for AArch32. +Adds additional problems for VA on top of the x86-64 specific VA problems. + +Host versus Guest? + - Host is everything inside of FEX code + - Guest is the application being emulated + +Thunks cause pain: + - What is a thunk? + - A bridge library between the x86/x86-64 guest library and a true AArch64 host library. + +TL;DR: VA reservation for guest applications that take a short amount of time completely dominate execution time. Things like `ls`, `echo`, `cat` +``` +**End of minor Information** + +**FEX+64Bit:** + - Common problems: + - Guest can not allocate memory in the 48-bit VA space + + - Current workarounds: + - Allocate 128TB of VA space on application startup in the 48-bit range + - Takes **5-20ms**, benchmarked on Apple M1. Cortex is slower. + - Only on >= 48-bit VA. Anything setup with smaller VA is spared this horror. + - Thunks Off: + - FEX controls all guest syscalls + - All *guest* memory allocation syscalls must return data in the VA range below 47-bit to match x86-64 + - All *host* memory allocations are unrestricted and can be allowed to go in to the 48-bit range + + - Problem examples: + - Guest application loads shared library with `mmap(nullptr, <size>, <prot>, <flags>, <fd>, <some offset>)` + - This needs to return in the lower 47-bit + - Guest application does an ioctl syscall, which calls IOCTL_DRM, allocates buffer + - This needs to return in the lower 47-bit + - Guest application does mmap with MAP_32BIT flag + - This doesn't exist on ARM + - Use mmap_range to restrict the range INSIDE of the prctl range to match 32-bit x86 range + - Range is [0x4000'0000, 0x8000'0000) + - FEX internal allocator calls mmap to allocate some memory + - This can return in the entire unrestricted 48-bit VA range. + + - Possible solutions + - typedef struct va_limit { uint64_t lower_bound, uint64_t upper_bound }; + - Lower bound provided since other emulators can reuse this as a base_offset limit + - **prctl(PR_SET_VA_LIMITS, const struct va_limit *limit);** + - Sets the VA limits, clamping to the range of configured VA (TASK_SIZE_64) so that mmap won't return bad values + - Fixes mmap, mmap2, mremap, shmat, ioctl memory allocations to ensure they fit inside the range. + - Does /NOT/ fix FEX wanting to freely allocate + - See following *_range syscalls + - memory allocation with MAP_FIXED/MAP_FIXED_NOREPLACE should still work outside this limit. + - **prctl(PR_GET_VA_LIMITS, struct va_limit *limit);** + - Gets the current set VA limits. Introspection as to what the current VA limit is and ensuring restriction was set. + + - mmap_range(uint64_t begin_range, uint64_t end_range, size_t size, int prot, int flags, int fd, off_t offset); + - mremap_range(void *old_address, size_t old_size, size_t new_size, int flags, uint64_t begin_range, uint64_t end_range); + - Useful for MREMAP_MAYMOVE + - shmat_range(int shmid, uint64_t begin_range, uint64_t end_range, int shmflg); + - Else restrict range to range provided + - ioctl_range - *Nope* - use prctl to limit its allocation range. + + - For each of the syscalls that have a begin_range and end_range + - if begin_range < end_range + - Allowed allocation region must fit fully within [begin_range, end_range) exclusive + - if begin_range == end_range + - behave like their non-ranged versions + - if begin_range > end_range + - This should cause the range to wrap around + - This allows the SET_VA_LIMITS prctl to place the limit at an `lower_bound` offset greather than 0 (or 0x1'0000 since + first 16kb is preotected). This means that you can allocate around the hole of memory still + + - Thunks On: + - FEX no longer controls all syscalls. + - Syscalls inside of the emulated space are still captured. + - Syscalls from a thunk library (like libGL) are uncaptured + - All *guest AND thunk* memory allocation syscalls must return data in the VA range below 47-bit to match x86-64 + - FEX itself can still allocate in 48-bit range fine. + + - Problem examples: + - AArch64 glibc loads shared library thunk with `mmap(nullptr, <size>, <prot>, <flags>, <fd>, <some offset>)` + - This needs to return in the lower 47-bit + - AArch64 thunk libraries need to be returned in same guest address space because of returning local pointers. + - AArch64 thunked library does an ioctl syscall, which calls IOCTL_DRM, allocates buffer + - This needs to return in the lower 47-bit + - FEX internal allocator calls mmap to allocate some memory + - This can return in the entire unrestricted 48-bit VA range. + + - Possible solutions + - Same solutions as Thunks off + +FEX+32Bit: + - Common problems: + - Guest can not allocate memory in the >4GB VA space + - Current workarounds: + - Allocate all VA space above 4GB. Up to 256TB (subtract 4GB) of VA space + - Takes **50-100 ms**, benchmarked on Apple M1. Cortex is slower. + - Additional time comes from searching for holes in the space due to library allocations already existing. + + - Thunks Off: + - FEX controls all guest syscalls + - All *guest* memory allocation syscalls must return data in the VA range below 4GB to match 32-bit x86 + - All *host* memory allocations are unrestricted and can be allowed to go in to the 48-bit range + + - Problem examples: + - Guest application loads shared library with `mmap(nullptr, <size>, <prot>, <flags>, <fd>, <some offset>)` + - This needs to return in the lower 4GB + - Guest application does an ioctl syscall, which calls IOCTL_DRM, allocates buffer + - This needs to return in the lower 4GB + - FEX internal allocator calls mmap to allocate some memory + - This can return in the entire unrestricted 48-bit VA range. + + - Possible solutions: + Same solutions as the 64-bit side, but instead of restricting ranges to the lower 47-bits, restricting ranges to the lower 4GB. + + - Thunks On: + - FEX no longer controls all syscalls. + - Syscalls inside of the emulated space are still captured. + - Syscalls from a thunk library (like libGL) are uncaptured + - All *guest AND thunk* memory allocation syscalls must return data in the VA range below 4GB to match 32-bit x86 + - FEX itself can still allocate in 48-bit range fine. + + - Problem examples: + - AArch64 glibc loads shared library thunk with `mmap(nullptr, <size>, <prot>, <flags>, <fd>, <some offset>)` + - This needs to return in the lower 4GB + - AArch64 thunk libraries need to be returned in same guest address space because of returning local pointers. + - AArch64 thunked library does an ioctl syscall, which calls IOCTL_DRM, allocates buffer + - This needs to return in the lower 4GB + - FEX internal allocator calls mmap to allocate some memory + - This can return in the entire unrestricted 48-bit VA range. + + - Possible solutions + - Same solutions as Thunks off + +Possible pain points: + - A thunk library allocating memory might pick up on FEX's internal memory allocator. + - This can be fixed with time and symbol visibility fixes + - For now FEX might leak /some/ data in to guest VA range when thunks are enabled + - Thunks not enabled there is no leak \ No newline at end of file diff --git a/results/scraper/fex/171 b/results/scraper/fex/171 new file mode 100644 index 000000000..03cee09a7 --- /dev/null +++ b/results/scraper/fex/171 @@ -0,0 +1,3 @@ +Make sure External projects can't include FEX headers +It's easy to mess up and accidentally include a FEX header in to FEXCore. +This should never occur. Fix the cmake setup so FEXCore can never include FEX headers. \ No newline at end of file diff --git a/results/scraper/fex/1710 b/results/scraper/fex/1710 new file mode 100644 index 000000000..c78fe29e0 --- /dev/null +++ b/results/scraper/fex/1710 @@ -0,0 +1,4 @@ +Repurpose the smc test apps for smc tests, add to test suite +Follow up from #1558 + +Current test apps in https://github.com/FEX-Emu/fex-assorted-tests-bins \ No newline at end of file diff --git a/results/scraper/fex/1711 b/results/scraper/fex/1711 new file mode 100644 index 000000000..1f885908f --- /dev/null +++ b/results/scraper/fex/1711 @@ -0,0 +1,2 @@ +Implement SHA1 +What it says on the tin. \ No newline at end of file diff --git a/results/scraper/fex/1712 b/results/scraper/fex/1712 new file mode 100644 index 000000000..d7909da3e --- /dev/null +++ b/results/scraper/fex/1712 @@ -0,0 +1,2 @@ +Implement SHA2 +What it says on the tin. \ No newline at end of file diff --git a/results/scraper/fex/1713 b/results/scraper/fex/1713 new file mode 100644 index 000000000..6909a0066 --- /dev/null +++ b/results/scraper/fex/1713 @@ -0,0 +1,2 @@ +Implement CLMUL +PMUL is the equivalent instruction. \ No newline at end of file diff --git a/results/scraper/fex/1714 b/results/scraper/fex/1714 new file mode 100644 index 000000000..da2028fd9 --- /dev/null +++ b/results/scraper/fex/1714 @@ -0,0 +1,4 @@ +Guest state reconstruction from synchronous SIGSEGV, SIGBUS for Unity +Split from #1682 and #1666, aiming to implement what is needed for Unity. + +Initial approach: writeback to context before load/store mem, hopefully that is enough. \ No newline at end of file diff --git a/results/scraper/fex/1715 b/results/scraper/fex/1715 new file mode 100644 index 000000000..bfa6d798c --- /dev/null +++ b/results/scraper/fex/1715 @@ -0,0 +1,6 @@ +Host deferred signals +This is an alternative way for us to avoid signal reentrancy amplification issues, vs blocking signals. + +Split from #1666, + +> (a) Is easy to do by adding a "is signal pending" check before returns to the JIT (syscalls, compile code, other non-thunks). This can be easily done either in the dispatcher/jit side, or the C++ side. The only complication is automatically restarted system calls. It has near zero overhead, and doesn't suffer from execution 'overshot' of guest deferred signal, just delayed signal delivery. This will largely resolve signal safety issues. diff --git a/results/scraper/fex/1717 b/results/scraper/fex/1717 new file mode 100644 index 000000000..dde7b98e3 --- /dev/null +++ b/results/scraper/fex/1717 @@ -0,0 +1,5 @@ +Reclaim SRA registers when running 32-bit x86 applications +Currently FEX hardcodes GPR and FPR static register allocation to be 16 registers apiece. +This is wasteful on 32-bit x86 since those applications only have access to 8 GPRs and 8 FPRs (plus MMX but we don't SRA though). + +If we are running a 32-bit application we should change our register allocator so it reclaims those remaining 8+8 registers as temporaries. This should give 32-bit applications a minor performance boost but nothing significant. \ No newline at end of file diff --git a/results/scraper/fex/1723 b/results/scraper/fex/1723 new file mode 100644 index 000000000..b39358e32 --- /dev/null +++ b/results/scraper/fex/1723 @@ -0,0 +1,71 @@ +Can't compile thunks on Arch Linux: undefined reference +In Asahi Linux with a 4K page kernel, I installed the following dependencies with pacman: +``` +git +cmake +ninja +clang +lld +sdl2 +libepoxy +squashfs-tools +squashfuse +``` +I then attempted to build FEX with cmake options `-DBUILD_THUNKS=True` and `-DBUILD_TESTS=False` (if I omit `-DBUILD_THUNKS=True`, the build succeeds) with the following error: +``` +FAILED: Bin/thunkgen +: && /usr/bin/clang++ -flto=thin -fPIE -pie ThunkLibs/Generator/CMakeFiles/thunkgen.dir/main.cpp.o -o Bin/thunkgen ThunkLibs/Generator/libthunkgenlib.a -lclangTooling /usr/lib/libcrypto.so && : +/usr/bin/ld: cannot find -lclangTooling: No such file or directory +``` +If I place a symlink to libclang-cpp.so in /usr/lib named libclangTooling.so, I get the following error: +``` +FAILED: Bin/thunkgen +: && /usr/bin/clang++ -flto=thin -fPIE -pie ThunkLibs/Generator/CMakeFiles/thunkgen.dir/main.cpp.o -o Bin/thunkgen ThunkLibs/Generator/libthunkgenlib.a -lclangTooling /usr/lib/libcrypto.so && : +/usr/bin/ld: /tmp/lto-llvm-004eb0.o: undefined reference to symbol '_ZN4llvm3vfs17getRealFileSystemEv@@LLVM_13' +/usr/bin/ld: /usr/lib/libLLVM-13.so: error adding symbols: DSO missing from command line +clang-13: error: linker command failed with exit code 1 (use -v to see invocation) +``` + +Using lld with `-DENABLE_LLD=True` yields a similar error: +``` +FAILED: Bin/thunkgen +: && /usr/bin/clang++ -flto=thin -fuse-ld=lld -fPIE -pie ThunkLibs/Generator/CMakeFiles/thunkgen.dir/main.cpp.o -o Bin/thunkgen ThunkLibs/Generator/libthunkgenlib.a -lclangTooling /usr/lib/libcrypto.so && : +ld.lld: error: undefined symbol: llvm::vfs::getRealFileSystem() +>>> referenced by main.cpp +>>> lto.tmp:(main) + +ld.lld: error: undefined symbol: llvm::deallocate_buffer(void*, unsigned long, unsigned long) +>>> referenced by main.cpp +>>> lto.tmp:(llvm::MallocAllocator::Deallocate(void const*, unsigned long, unsigned long)) + +ld.lld: error: undefined symbol: llvm::SmallVectorBase<unsigned int>::grow_pod(void*, unsigned long, unsigned long) +>>> referenced by gen.cpp +>>> lto.tmp:(llvm::SmallVectorTemplateCommon<llvm::PointerIntPair<clang::Stmt*, 1u, bool, llvm::PointerLikeTypeTraits<clang::Stmt*>, llvm::PointerIntPairInfo<clang::Stmt*, 1u, llvm::PointerLikeTypeTraits<clang::Stmt*> > >, void>::grow_pod(unsigned long, unsigned long)) +>>> referenced by gen.cpp +>>> lto.tmp:(llvm::SmallVectorTemplateCommon<std::pair<void*, unsigned long>, void>::grow_pod(unsigned long, unsigned long)) +>>> referenced by gen.cpp +>>> lto.tmp:(llvm::SmallVectorTemplateCommon<void*, void>::grow_pod(unsigned long, unsigned long)) + +ld.lld: error: undefined symbol: llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) +>>> referenced by gen.cpp +>>> lto.tmp:(clang::FunctionProtoType::getExceptionSpecSize(clang::ExceptionSpecificationType, unsigned int)) +>>> referenced by gen.cpp +>>> lto.tmp:(clang::RecursiveASTVisitor<ASTVisitor>::TraverseAttr(clang::Attr*)) + +ld.lld: error: undefined symbol: llvm::allocate_buffer(unsigned long, unsigned long) +>>> referenced by gen.cpp +>>> lto.tmp:(llvm::MallocAllocator::Allocate(unsigned long, unsigned long)) + +ld.lld: error: undefined symbol: llvm::APInt::APInt(unsigned int, unsigned int, unsigned long const*) +>>> referenced by gen.cpp +>>> lto.tmp:(clang::APNumericStorage::getIntValue() const) + +ld.lld: error: undefined symbol: llvm::APInt::initSlowCase(unsigned long, bool) +>>> referenced by gen.cpp +>>> lto.tmp:(llvm::APInt::APInt(unsigned int, unsigned long, bool)) + +ld.lld: error: undefined symbol: llvm::APInt::countLeadingZerosSlowCase() const +>>> referenced by gen.cpp +>>> lto.tmp:(llvm::APInt::countLeadingZeros() const) +clang-13: error: linker command failed with exit code 1 (use -v to see invocation) +``` diff --git a/results/scraper/fex/1729 b/results/scraper/fex/1729 new file mode 100644 index 000000000..3a48cf26f --- /dev/null +++ b/results/scraper/fex/1729 @@ -0,0 +1,16 @@ +Can we optimize non-locking RMW atomic operations? +Currently we convert all lock RMW ops to acquire-release semantics. + +Couple weird things to investigate here + +1. Basic ALU ops without lock + - Non-lock ops get turned in to load + ALU + store + - Can potentially convert in to atomic memory operation **without** acquire-release semantics. + - Should only generate on ARMv8.1+ if it supports atomic memory ops + - Might need hardware TSO support? + 2. RMW ops that don't imply LOCK but really should, used without LOCK + - **CMPXCHG, CMPXCHG8B, CMPXCHG16B, XADD** + - These instructions don't imply LOCK prefixes but they are almost universally used with them + - Linux kernel has some optimization where it backpatches `lock cmpxchg` in to `nop cmpxchg` on uniprocessors? Citation needed. + - These might be able to be converted to operations with...release? semantics? + - Needs investigation. diff --git a/results/scraper/fex/173 b/results/scraper/fex/173 new file mode 100644 index 000000000..200abd850 --- /dev/null +++ b/results/scraper/fex/173 @@ -0,0 +1,12 @@ +Bit accurate Transcendental support +This is a long term goal. +Currently we don't offer bit accurate transcendental instructions. +Reciprocal and reciprocal square root instructions have a fairly large range for their precision support. +These are currently implemented with float divisions to ensure all of the CPU backends match results and have same unit test results. + +These precision differences have the fun quirk that usually something like the reciprocal of 1.0f results in a result that isn't 1.0f even. + +We should have support for a few modes once this gets worked on. +1) Bit accurate representation that matches *SOME* known hardware +2) Most accurate representation (What we have now) +3) Accuracy that falls within x86 precision requirements, but doesn't match any known hardware (In case any device supports less accurate results that are still within x86 spec) \ No newline at end of file diff --git a/results/scraper/fex/1731 b/results/scraper/fex/1731 new file mode 100644 index 000000000..4325c7818 --- /dev/null +++ b/results/scraper/fex/1731 @@ -0,0 +1,68 @@ +Idea for partial TSO cost mitigation/pgo with MTE extensions +Following up from yesterday's discussion, + +#### Overview +Using `MTE` (https://www.kernel.org/doc/html/latest/arm64/memory-tagging-extension.html) which tracks a 4-bit tag per 16 bytes of memory we can mark every 16 bytes of memory as either being `local` to a cpu core, thus `non-tso` accesses are fine, or as `shared`, thus accesses need to be `tso`. MTE gives us 4 bits, so we can track up to 15 cpu cores plus 1 id used for `shared` memory. + +The `rseq` (https://www.efficios.com/blog/2019/02/08/linux-restartable-sequences/) kernel feature can be used to detect when a task is switched between cpu cores. + +We can then detect `non-tso` accesses to `shared` and `tso` accesses to `local` memory with a synchronous tag mismatch exception, and backpatch the offending instruction to use slower, tso instructions. + +The optimisation depends on `local`/`shared` memory access being a characteristic of the specific memory operation. While this is overall likely to be true, functions like memcpy will have to deal with both `shared` and `local` memory. + +There are several limitations to this approach, however it should still be useful for instrumentation and pgo. + +#### Limitations +- Ping-ponging between `tso` and `non-tso` access modes. I'm not sure there's a good workaround for that, as I don't think we can allow TSO ops to work on both `local` and `shared` memory using MTE +- Thunks could have issues +- Object code caching would be possible, but backpatching has to be done per vm group increasing the memory load +- Linux doesn't support PROT_MTE with non ram file-backed mappings `PROT_MTE is only supported on MAP_ANONYMOUS and RAM-based file mappings (tmpfs, memfd).` +- Can only support up to 15 host cpu cores +- While tso ops need only to be done in `shared` memory accesses, not all `shared` memory accesses need to be tso. It is impossible to detect `shared` accesses that don't need to be `tso` using this approach. + +#### Variations +- The actual memops could be interpreted in the segfault handler, either to guarantee forward progress and/or limit backpatching + +#### Details + +##### Setup +- Compute `HostCoreId` as such that they are either [0,14] with 15 reserved for `shared` memory, or as [1, 15] with 0 reserved for `shared` memory. +- Extend the guest cpu frame to have a "current cpu core mte id" field, `frame->HostCoreId` +- Dedicate a caller saved register in the jit to shadow this value, `rHostCoreId` +- Reload `rHostCoreId` from `frame->HostCoreId` on every re-enter to the jit abi +- Using rseq, keep `frame->HostCoreId` in sync with the current `HostCoreId`. An alternative is to read from the rseq core id field. +- Using rseq, update `rHostCoreId` on cpu core migration if the code is in the jit abi + +Assuming 0 is used to indicate `shared` memory + +##### `local` memops +``` +[0] rAddr = x86AddressGen(...) +[1] bfi rAddr[59:56], rHostCoreId +[2] non-tso memop rAddr, data, .... +``` + +##### `shared` memops +``` +[0] rAddr = x86AddressGen(...) +[1] bfc rAddr[59:56] +[2] tso memop rAddr, data, .... +``` + +##### `local` -> `shared` migration & backpatching +- on `SIGSEGV` with `.si_code = SEGV_MTESERR` where the offending memop is a `non-tso` memop +- take some lock +- change `.si_addr` TAG to 0 +- backpatch memop[1] to bfc +- backpatch memop[2] to `tso` memop +- release lock +- re-execute the sequence + +##### `shared` -> `local` migration & backpatching +- on `SIGSEGV` with `.si_code = SEGV_MTESERR` where the offending memop is a `tso` memop +- take some lock +- change `.si_addr` TAG to `CoreId` +- backpatch memop[1] to bfi +- backpatch memop[2] to `non-tso` memop +- release lock +- re-execute the sequence diff --git a/results/scraper/fex/1732 b/results/scraper/fex/1732 new file mode 100644 index 000000000..655145298 --- /dev/null +++ b/results/scraper/fex/1732 @@ -0,0 +1,8 @@ +TME extension: ideas on how to (ab)use it +Following up from yesterday's discussion, + +For `tso`/`non-tso` memory tracking, we might be able to group accesses between atomic ops in transactions, and detect concurrent access with transaction aborts. Might get us more precise tracking than the [MTE](https://github.com/FEX-Emu/FEX/issues/1731) approach. + +For synchronous detection of segfaults, we might be able to wrap code between guest abi sync points around a transaction, and on transaction abort execute some slowpath. Details on synchronous signal complications in #1682 + +TME Extension details: https://developer.arm.com/documentation/101028/0012/16--Transactional-Memory-Extension--TME--intrinsics?lang=en \ No newline at end of file diff --git a/results/scraper/fex/1733 b/results/scraper/fex/1733 new file mode 100644 index 000000000..e2c636845 --- /dev/null +++ b/results/scraper/fex/1733 @@ -0,0 +1,2 @@ +ThunkLibs/gen: Changes to dependencies of interface files are not tracked by cmake/ninja +Not sure if there is a fix for this. \ No newline at end of file diff --git a/results/scraper/fex/1740 b/results/scraper/fex/1740 new file mode 100644 index 000000000..15080afbd --- /dev/null +++ b/results/scraper/fex/1740 @@ -0,0 +1,2 @@ +CI: Why is struct verifier breaking? +Followup to CI upgrades. \ No newline at end of file diff --git a/results/scraper/fex/1741 b/results/scraper/fex/1741 new file mode 100644 index 000000000..0407d6968 --- /dev/null +++ b/results/scraper/fex/1741 @@ -0,0 +1,2 @@ +CI: New gvisor test breaks +Due to CI upgrades. \ No newline at end of file diff --git a/results/scraper/fex/1742 b/results/scraper/fex/1742 new file mode 100644 index 000000000..141e96621 --- /dev/null +++ b/results/scraper/fex/1742 @@ -0,0 +1,2 @@ +CI: Atomic interpreter test on ARMv8 break +Due to CI upgrades. \ No newline at end of file diff --git a/results/scraper/fex/1743 b/results/scraper/fex/1743 new file mode 100644 index 000000000..37183fbb4 --- /dev/null +++ b/results/scraper/fex/1743 @@ -0,0 +1,4 @@ +Investigate which SHA instructions can be replaced with native instructions. +Followup to #1739. +Current implementation is GPR only. +Look at AArch64's SHA1 instructions and see where we can replace instructions with the hardware acceleration instructions. \ No newline at end of file diff --git a/results/scraper/fex/1750 b/results/scraper/fex/1750 new file mode 100644 index 000000000..0d5bf73a0 --- /dev/null +++ b/results/scraper/fex/1750 @@ -0,0 +1,2 @@ +Update to upstream gvisor tests +Follow up from #1741 \ No newline at end of file diff --git a/results/scraper/fex/1753 b/results/scraper/fex/1753 new file mode 100644 index 000000000..f01ab4822 --- /dev/null +++ b/results/scraper/fex/1753 @@ -0,0 +1,2 @@ +Is FEX possible to run in termux p-root +I'm just wondering if FEX requires things like init or access to proc or dev/dri as p-root container doesn't have access to those? I want to try and see if I can run fluent on an android phone. \ No newline at end of file diff --git a/results/scraper/fex/1754 b/results/scraper/fex/1754 new file mode 100644 index 000000000..1fa3dedbb --- /dev/null +++ b/results/scraper/fex/1754 @@ -0,0 +1,6 @@ +FexLinuxTests backlog +An internal backlog of tests (mostly for me), so the tracker is not spammed with too many of these tickets. + +If you have any corner cases that you want tested, or ideas for edge case behaviour we don't cover feel free to leave a comment here and I'll generate a test case, as time allows. + +This is meant for "nice to have" tests, and not as a general way to avoid including tests with future PRs \ No newline at end of file diff --git a/results/scraper/fex/1765 b/results/scraper/fex/1765 new file mode 100644 index 000000000..6a8933864 --- /dev/null +++ b/results/scraper/fex/1765 @@ -0,0 +1,26 @@ +SMC: Compile code needs to mprotect before reading, or stale core might be run +More likely to happen in the armv8.0 runner +``` +read/modify/segfault (no write made) +code cache flush +{other thread starts compiling here} +read/modify/write +{other thread finishes compiling, mprotects} +stale code gets run +``` + +CI failure +https://github.com/FEX-Emu/FEX/runs/6825655440?check_suite_focus=true#step:27:132 +``` +[DEBUG] Host CPU doesn't support atomics. Expect bad performance +[Info] Migrating to shared memory mode +Generating code on thread +Waiting for code to be modified +Modifying code from another thread +Waiting for thread to get unblocked +Thread overshoot once, this is non fatal +Thread should have been patched to not modify counter here +test failed, expected is 0 but got 1 +``` + +Also, tear-tests should be run a statistically important number of times to catch these cases \ No newline at end of file diff --git a/results/scraper/fex/1768 b/results/scraper/fex/1768 new file mode 100644 index 000000000..65ef7cc15 --- /dev/null +++ b/results/scraper/fex/1768 @@ -0,0 +1,4 @@ +Add backtrace on std::terminate calls +https://stackoverflow.com/questions/3355683/c-stack-trace-from-unhandled-exception + +https://eli.thegreenplace.net/2015/programmatic-access-to-the-call-stack-in-c/ \ No newline at end of file diff --git a/results/scraper/fex/1772 b/results/scraper/fex/1772 new file mode 100644 index 000000000..dc6699386 --- /dev/null +++ b/results/scraper/fex/1772 @@ -0,0 +1,14 @@ +TCBs: Track metadata fragment metadata internally, not in InternalThreadState::DebugStore +#### Current Situation +Currently, debug metadata is tracked by its guest entrypoint, and it is assumed that there's an 1:1 mapping between fragments and guest entry points. + +There are a number of cases where this is not true. The current fragment may be invalidated, but still executing. eg +- Cross thread SMC invalidation +- Signal or thunk return +- Shared memory mode migration +- Possibly others + +There is also a race condition, as debug metadata corresponds to a specific version of a fragment, however a guest entrypoint is inherently not versioned. + +#### Proposal +We can track debug (and other) metadata, as part of the host fragment translation. This way, we will be able to locate the correct version. Metadata clearing will also become a responsibility of the backend, which will reduce the context's responsibilities. To get debug data for a specific translation, a host TCB ptr will be required. \ No newline at end of file diff --git a/results/scraper/fex/1774 b/results/scraper/fex/1774 new file mode 100644 index 000000000..351d3bb32 --- /dev/null +++ b/results/scraper/fex/1774 @@ -0,0 +1,43 @@ +Support thunking of multi-instance Vulkan applications +FEX's libvulkan thunks don't work if multiple `VkInstances` are used that return different function pointers to `vkGetDeviceProcAddr`. This is because to implement `vkGetDeviceProcAddr` in the first place, FEX needs to pre-query a `VkInstance`-specific function pointer during initialization. The function pointer itself is called without any direct reference to the original `VkInstance`, so FEX acts as if only the first VkInstance created by the application was used. + +In the broader picture, the problem is a restriction in the thunk generator: Functions that must be guest-callable through host function pointers can not use a custom guest entrypoint. + +### Suggested solution: Extending framework for guest-callable host function pointers + +Currently, guest-callable host function pointers are implemented by linking the host function pointer to a generic template function that forwards the packed argument list *plus* the original host function pointer to a `hostcall_` thunk. In this case, the function pointer is `vkGetDeviceProcAddr` as returned from `vkGetInstanceProcAddr`. What's needed is a way of customizing the target function: Instead of calling the thunk that initiates a Guest->Host transition, a custom function should be called. + +Implementation sketch of the guest-side thunk library: +```cpp +template<auto Function, typename Result, typename... Args> +inline Result ReadHiddenArgumentAndCall(Args... args) { + uintptr_t hidden_arg; + asm("mov %%rax, %0" : "=r" (hidden_arg)); + return Function(args..., hidden_arg); +} + +PFN_vkVoidFunction vkGetDeviceProcAddr_indirect(VkDevice a_0, const char* a_1, void* host_ptr) { + PackedArguments<PFN_vkVoidFunction, VkDevice, const char*, uintptr_t> args = { a_0, a_1, host_ptr }; + fexthunks_libvulkan_hostcall_vkGetDeviceProcAddr(&args); + LinkGuestAddressToHostFunction(args.rv, PtrsToLookUp.at(a_1)); + return args.rv; +} + +#if 0 +// For illustration only: Public entrypoint of this function (if it were needed) +PFN_vkVoidFunction vkGetDeviceProcAddr(VkDevice a_0, const char* a_1) { + return vkGetDeviceProcAddr_indirect(a_0, a_1, fexldr_ptr_vkGetDeviceProcAddr); +} +#endif + +PFN_vkVoidFunction vkGetInstanceProcAddr(VkInstance a_0, const char* a_1){ + auto Ret = fexfn_pack_vkGetInstanceProcAddr(a_0, a_1); + if (a_1 != std::string_view { "vkGetDeviceProcAddr" }) { + LinkGuestAddressToHostFunction(Ret, PtrsToLookUp.at(a_1)); + return Ret; + } else { + LinkGuestAddressToHostFunction(Ret, ReadHiddenArgumentAndCall<vkGetDeviceProcAddr_indirect>); + return Ret; + } +} +``` diff --git a/results/scraper/fex/1780 b/results/scraper/fex/1780 new file mode 100644 index 000000000..f94233d31 --- /dev/null +++ b/results/scraper/fex/1780 @@ -0,0 +1,2 @@ +Introduce structs for std::tuples that have crept in, types for std::functions as needed +Follow up from https://github.com/FEX-Emu/FEX/pull/1770#discussion_r899318747 \ No newline at end of file diff --git a/results/scraper/fex/1791 b/results/scraper/fex/1791 new file mode 100644 index 000000000..8c882dd38 --- /dev/null +++ b/results/scraper/fex/1791 @@ -0,0 +1,26 @@ +Aggressive spilling when initializing large unordered_maps +While working on #1760, I hit an interesting edge case in our JIT: Initializing large `std::unordered_map`s (>3000 entries) causes the JIT to spill a lot of registers, but only if the running application was compiled with optimizations enabled. + +Steps to reproduce: +1. Write a list of all libGL functions to `mylist.inl` using +``` +<FEX-build-folder>/Bin/thunkgen ThunkLibs/libGL/libGL_interface.cpp libGL -symbol_list mylist.inl -- -std=c++17 -isystem ThunkLibs/include/ +``` +2. Create a new file called `test.cpp` with these contents: +```cpp +#include <cstdint> +#include <unordered_map> +#include <string_view> +#include "mylist.inl" + +static std::unordered_map<std::string_view, uintptr_t> HostPtrInvokers{}; + +int main() { +#define PAIR(name, unused) { #name, 0 }, + HostPtrInvokers = { + FOREACH_internal_SYMBOL(PAIR) + }; +} +``` +3. Compile for x86-64 using `x86_64-linux-gnu-g++ -O0 test.cpp`. Running the output binary in FEX should quickly finish. +4. Compile for x86-64 using `x86_64-linux-gnu-g++ -O2 test.cpp`. This optimized binary takes several seconds to run in FEX diff --git a/results/scraper/fex/1793 b/results/scraper/fex/1793 new file mode 100644 index 000000000..e1d03a23f --- /dev/null +++ b/results/scraper/fex/1793 @@ -0,0 +1,38 @@ +Looks like this is causing Interpreter to crash when running at least vulkaninfo (without thunks). +Looks like this is causing Interpreter to crash when running at least vulkaninfo (without thunks). + +Couple of different crashes. +``` +Thread 1 "FEXLoader" received signal SIGSEGV, Segmentation fault. +Xbyak::CodeArray::isAutoGrow (this=0x0) at /mnt/Work/Work/work/FEXNew/External/xbyak/xbyak/xbyak.h:1107 +1107 bool isAutoGrow() const { return type_ == AUTO_GROW; } +(gdb) bt +#0 Xbyak::CodeArray::isAutoGrow (this=0x0) at /mnt/Work/Work/work/FEXNew/External/xbyak/xbyak/xbyak.h:1107 +#1 0x00005555557f4cb7 in Xbyak::LabelManager::define_inner<std::unordered_map<int, Xbyak::LabelManager::ClabelVal, std::hash<int>, std::equal_to<int>, std::allocator<std::pair<int const, Xbyak::LabelManager::ClabelVal> > >, std::unordered_multimap<int, Xbyak::JmpLabel const, std::hash<int>, std::equal_to<int>, std::allocator<std::pair<int const, Xbyak::JmpLabel const> > >, int> (this=0x7ffff7763140, defList=std::unordered_map with 0 elements, undefList=std::unordered_multimap with 0 elements, labelId=@0x7fffffffc6ac: 1, addrOffset=24) at /mnt/Work/Work/work/FEXNew/External/xbyak/xbyak/xbyak.h:1345 +#2 0x00005555557f49e0 in Xbyak::LabelManager::defineClabel (this=0x7ffff7763140, label=...) at /mnt/Work/Work/work/FEXNew/External/xbyak/xbyak/xbyak.h:1451 +#3 0x00005555557e80c4 in Xbyak::CodeGenerator::L (this=0x7ffff77630b0, label=...) at /mnt/Work/Work/work/FEXNew/External/xbyak/xbyak/xbyak.h:2370 +#4 0x00005555557e8f98 in FEXCore::CPU::X86Dispatcher::GenerateInterpreterTrampoline (this=0x7ffff7763000, CodeBuffer=0x7fffe273a9d8 "L\211\367H\215\065") at /mnt/Work/Work/work/FEXNew/External/FEXCore/Source/Interface/Core/Dispatcher/X86Dispatcher.cpp:456 +#5 0x0000555555897853 in FEXCore::CPU::InterpreterCore::CompileCode (this=0x7ffff762d480, Entry=140736973056609, IR=0x7ffff7795d30, DebugData=0x7ffff7795d60, RAData=0x0, GDBEnabled=false) at /mnt/Work/Work/work/FEXNew/External/FEXCore/Source/Interface/Core/Interpreter/InterpreterCore.cpp:80 +#6 0x00005555556f0074 in FEXCore::Context::Context::CompileCode (this=0x7ffff7694000, Thread=0x7ffff7690000, GuestRIP=140736973056609) at /mnt/Work/Work/work/FEXNew/External/FEXCore/Source/Interface/Core/Core.cpp:948 +#7 0x00005555556f028f in FEXCore::Context::Context::CompileBlock (this=0x7ffff7694000, Frame=0x7ffff76901b0, GuestRIP=140736973056609) at /mnt/Work/Work/work/FEXNew/External/FEXCore/Source/Interface/Core/Core.cpp:989 +#8 0x00005555556f0149 in FEXCore::Context::Context::CompileBlockJit (this=0x7ffff7694000, Frame=0x7ffff76901b0, GuestRIP=140736973056609) at /mnt/Work/Work/work/FEXNew/External/FEXCore/Source/Interface/Core/Core.cpp:959 +``` + +or +``` +terminate called after throwing an instance of 'Xbyak::Error' + what(): label is not found + ``` +``` +(gdb) disas $pc,+32 +Dump of assembler code from 0x7fffd63ef8b2 to 0x7fffd63ef8d2: +=> 0x00007fffd63ef8b2: add BYTE PTR [rax],al + 0x00007fffd63ef8b4: add BYTE PTR [rax],al + 0x00007fffd63ef8b6: add BYTE PTR [rax],al + 0x00007fffd63ef8b8: add BYTE PTR [rax],al + 0x00007fffd63ef8ba: add BYTE PTR [rax],al + ``` + +This is on an x86 host, interpreter, 500 inst, no-multiblock, Ubuntu 22.04 without rootfs. + +_Originally posted by @Sonicadvance1 in https://github.com/FEX-Emu/FEX/issues/1782#issuecomment-1164140882_ \ No newline at end of file diff --git a/results/scraper/fex/1798 b/results/scraper/fex/1798 new file mode 100644 index 000000000..ddbd6fe19 --- /dev/null +++ b/results/scraper/fex/1798 @@ -0,0 +1,9 @@ +Performance with short lived processes +I'm trying to run many short lived command-line processes under FEX (a pre-compiled embedded GCC toolchain) and I'm wondering if there are configuration options that I can tune to achieve the best performance. + +I saw a -20% improvement with an unpacked RootFS compared to squashfs, but performance is far from native (6s to compile an hello world). Are there other options that can be tuned for this use case? + +It's my (limited) understanding that the transpiled ARM binary is not cached between different runs by default, but I'm not sure if it can be enabled. How are these options supposed to be used? +<img width="210" alt="image" src="https://user-images.githubusercontent.com/317661/175352029-5e6aed6b-6f93-4921-93d6-c769ff69bb72.png"> + +Thanks! diff --git a/results/scraper/fex/1807 b/results/scraper/fex/1807 new file mode 100644 index 000000000..8cbfd7ad2 --- /dev/null +++ b/results/scraper/fex/1807 @@ -0,0 +1,9 @@ +Classify ARM version rather than use runner_label +https://github.com/FEX-Emu/FEX/blob/4449b604597a6b23699a9cf18ec75761b053e078/unittests/ASM/CMakeLists.txt#L68 + +This line in the ASM cmake test uses runner_label directly. +This is kind of annoying when running unit tests locally and haven't set a runner label. +End up seeing "failing" tests but these are just disabled on some platforms. + +Instead we should classify the host CPU and choose the file directly. +The `InstallFEX.py` script has a way to classify CPU features to minimum versions that we can reuse. https://github.com/FEX-Emu/FEX/blob/main/Scripts/InstallFEX.py#L98 \ No newline at end of file diff --git a/results/scraper/fex/1808 b/results/scraper/fex/1808 new file mode 100644 index 000000000..9469e0539 --- /dev/null +++ b/results/scraper/fex/1808 @@ -0,0 +1,4 @@ +Create unit test for overflow exception checking +Brought up by #1806 that we don't have a unit test that is testing our overflow exception handling. +While I tested this locally, we don't have it in CI. +Create a test for this. \ No newline at end of file diff --git a/results/scraper/fex/1810 b/results/scraper/fex/1810 new file mode 100644 index 000000000..5ffdcce2a --- /dev/null +++ b/results/scraper/fex/1810 @@ -0,0 +1,7 @@ +vixl assert +https://github.com/FEX-Emu/FEX/blob/b020e593a5b34d8add4e86850f8bfeb155dc5223/External/FEXCore/Source/Interface/Core/Dispatcher/Arm64Dispatcher.cpp#L506 + +This line triggers an assert in vixl from a recent change. +assert line: https://github.com/FEX-Emu/vixl/blob/1a0fc0430855d4fe355edc1a0adcce15ee7e4ef7/src/code-buffer-vixl.cc#L73 + +CI doesn't compile with vixl asserts enabled which is why it wasn't hit there. \ No newline at end of file diff --git a/results/scraper/fex/1819 b/results/scraper/fex/1819 new file mode 100644 index 000000000..38916ba4b --- /dev/null +++ b/results/scraper/fex/1819 @@ -0,0 +1,2 @@ +Include thunks in CI build +So that PRs like #1812 don't get merged by accident \ No newline at end of file diff --git a/results/scraper/fex/1820 b/results/scraper/fex/1820 new file mode 100644 index 000000000..85fc0df19 --- /dev/null +++ b/results/scraper/fex/1820 @@ -0,0 +1,2 @@ +Thunk generator doesn't work with default clang package ubuntu 20.04 +Using clang-12 + clang-12-dev works (default is -10) \ No newline at end of file diff --git a/results/scraper/fex/1821 b/results/scraper/fex/1821 new file mode 100644 index 000000000..a2682d979 --- /dev/null +++ b/results/scraper/fex/1821 @@ -0,0 +1,14 @@ +FEXServer breaks unbreak_chroot.sh +skmp@ornio:~/.fex-emu/RootFS/Ubuntu_21_04$ ./unbreak_chroot.sh +Moving rootfs files back to original location +Moving rootfs folders back to original location +Moving rootfs apt folders back to original location +Changing rootfs permissions on /tmp +Mounting rootfs paths +Mounting aarch64 paths +Chrooting into container +!!! Make sure to execute break_chroot.sh after leaving !!! +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] FEXServerClient: Failure to setup client diff --git a/results/scraper/fex/1827 b/results/scraper/fex/1827 new file mode 100644 index 000000000..906813982 --- /dev/null +++ b/results/scraper/fex/1827 @@ -0,0 +1,24 @@ +Vulkan thunking support with DXVK +Currently enabling Vulkan thunking with DXVK in Wine currently results in crashing. +The initial issue is missing some X11 symbols in our X11 thunks, but then after that it seems like multiple conflicting issues + +## Installing DXVK +* Download DXVK from their Github Actions artifacts to get a recent build + * https://github.com/doitsujin/dxvk/actions/workflows/artifacts.yml?query=branch%3Amaster + * Extract + * `FEXBash` + * `export WINEPREFIX=/path/to/.wine-prefix` + * `./setup_dxvk.sh install` + +## Enable Vulkan thunks +* Enable thunks in a 64-bit Windows application that is D3D9/10/11 + * I use `dxcapsviewer.exe`, so create an app profile in `~/.fex-emu/AppConfigs/dxcapsviewer.exe.json` + * https://github.com/microsoft/DxCapsViewer/releases/tag/feb2022 +* Execute a D3D9/10/11 game with FEX+Wine +* `FEXBash "wine dxcapsviewer.exe"` +* Watch it explode + +## Helpful bits +* `export WINEDEBUG=+module` can give more information about why a library fails to load. +* Execute wineserver in the background to keep it around and reduce testing startup time + * `FEXBash "wineserver -f -p"` diff --git a/results/scraper/fex/1838 b/results/scraper/fex/1838 new file mode 100644 index 000000000..5c3c3bb88 --- /dev/null +++ b/results/scraper/fex/1838 @@ -0,0 +1,9 @@ +Vulkan thunking support with zink +While this isn't an ideal situation that an x86/x86-64 Zink is communicating with an AArch64 vulkan thunk, this should be a case we support. +Currently this crashes our Vulkan thunks + +``` +vkGetInstanceProcAddr: Couldn't find Guest symbol: 'vkGetInstanceProcAddr' +``` + +It searches for a bunch of vulkan symbols that don't exist so it definitely performs a bit odd compared to regular applications. \ No newline at end of file diff --git a/results/scraper/fex/1847 b/results/scraper/fex/1847 new file mode 100644 index 000000000..fc8cbf31c --- /dev/null +++ b/results/scraper/fex/1847 @@ -0,0 +1,17 @@ +Classify CoreState differently depending on if host supports AVX or not +Keep the XMM elements 256bit in size but classify them differently as a union or something. + +``` +union { +struct { +uint64_t XMM[16][4]; +} SupportsAVX; +struct { +uint64_t XMM[16][2]; +uint64_t _Pad[16][2]; +} NoSupportsAVX; +}; +``` + +This way we can still use LDP and STP still for non-SVE2 ARM. +Needs to set up the classification path to support both. diff --git a/results/scraper/fex/1853 b/results/scraper/fex/1853 new file mode 100644 index 000000000..fb4ba8e6a --- /dev/null +++ b/results/scraper/fex/1853 @@ -0,0 +1,18 @@ +docker build-FindSDL2.cmake +The error information is as follows，how to solve it？Thangk you！ + +CMake Error at Source/Tools/FEXConfig/CMakeLists.txt:7 (find_package): + By not providing "FindSDL2.cmake" in CMAKE_MODULE_PATH this project has + asked CMake to find a package configuration file provided by "SDL2", but + CMake did not find one. + + Could not find a package configuration file provided by "SDL2" with any of + the following names: + + SDL2Config.cmake + sdl2-config.cmake + + Add the installation prefix of "SDL2" to CMAKE_PREFIX_PATH or set + "SDL2_DIR" to a directory containing one of the above files. If "SDL2" + provides a separate development package or SDK, be sure it has been + installed. diff --git a/results/scraper/fex/1857 b/results/scraper/fex/1857 new file mode 100644 index 000000000..63f7732ef --- /dev/null +++ b/results/scraper/fex/1857 @@ -0,0 +1,6 @@ +Question about FEXRootFSFetcher +hello, + +I have installed FEX in a docker image but I need to run FEXRootFSFetcher ( when building the image) , then It should type "yes" and then "1" and then "2" but is there any way I can do this because there is no input when building a docker file? + +I can not do this after the image is build as the data need to be percistant. \ No newline at end of file diff --git a/results/scraper/fex/186 b/results/scraper/fex/186 new file mode 100644 index 000000000..23cc5c6d9 --- /dev/null +++ b/results/scraper/fex/186 @@ -0,0 +1,40 @@ +Ensure gettid == getpid +Currently FEX doesn't maintain that gettid == getpid. +This is noticed by some applications and confuses them. +We should ensure that the guest application's primary thread is FEX's primary thread. +The frontend should spin off its own worker threads instead. +Alternatively we can return the primary's guest thread's tid for the getpid syscall, but I think that may cause issues in some cases? +```cpp +#include <stdio.h> +#include <unistd.h> + +int main() { + pid_t pid = getpid(); + pid_t tid = gettid(); + if (pid != tid) { + printf("FAIL! Something is mucking with us! pid != tid ; %d != %d\n", pid, tid); + } + else { + printf("SUCCESS! TID == PID\n"); + } + return 0; +} +``` + +Real environment +```bash +ryanh@Ryan-TR2:~$ ./a.out +SUCCESS! TID == PID +``` + +FEX +```bash +ryanh@Ryan-TR2:~/work/FEXNew/Build$ ./Bin/ELFLoader -U -c irjit -n 500 -- ~/a.out +[DEBUG] We installed 2314 instructions to the tables +[DEBUG] Precompiling: 0 blocks... +[DEBUG] Done +FAIL! Something is mucking with us! pid != tid ; 30155 != 30157 +[DEBUG] Reason we left VM: 3 +[DEBUG] Used 1455012 bytes for compiling +[DEBUG] Managed to load? No +``` \ No newline at end of file diff --git a/results/scraper/fex/1867 b/results/scraper/fex/1867 new file mode 100644 index 000000000..e4b0316df --- /dev/null +++ b/results/scraper/fex/1867 @@ -0,0 +1,28 @@ +Enabling XCB thunks breaks steamwebhelper +Thunking for libxcb is currently not compatible with steamwebhelper. Steam will start fine, but no browser content will render. Looking at console output, steamwebhelper keeps being restarted over a SIGILL. This indicates the issue is related to function pointer thunking. + +Example config: +```json +{ +"ThunksDB": { +"GL": 0, +"xcb": 1, +"xcb-dri2": 1, +"xcb-dri3": 1, +"X11": 0, +"xcb-xfixes": 1, +"xcb-shm": 1, +"xcb-sync": 1, +"xcb-randr": 0, +"xcb-present": 0, +"xcb-glx": 1, +"xshmfence": 1, +"drm": 0, +"Xrender": 0, +"Xext": 0, +"Xfixes": 0, +"Vulkan": 0, +"asound": 0 +} +} +``` \ No newline at end of file diff --git a/results/scraper/fex/1871 b/results/scraper/fex/1871 new file mode 100644 index 000000000..8ca663a49 --- /dev/null +++ b/results/scraper/fex/1871 @@ -0,0 +1,4 @@ +x86 asm tests should run only if host / fex implement the features +My workstation has no BMI2. + +We should also refuse to run when the FEX minspec is not met. \ No newline at end of file diff --git a/results/scraper/fex/1872 b/results/scraper/fex/1872 new file mode 100644 index 000000000..055703e8b --- /dev/null +++ b/results/scraper/fex/1872 @@ -0,0 +1,4 @@ +CMake on X86 should default to a debug config +- IPR on +- All tests all +- Target: Debug \ No newline at end of file diff --git a/results/scraper/fex/1873 b/results/scraper/fex/1873 new file mode 100644 index 000000000..d16306717 --- /dev/null +++ b/results/scraper/fex/1873 @@ -0,0 +1 @@ +CMake on arm should default to RelWithDebInfo diff --git a/results/scraper/fex/1876 b/results/scraper/fex/1876 new file mode 100644 index 000000000..a9cbec276 --- /dev/null +++ b/results/scraper/fex/1876 @@ -0,0 +1,21 @@ +AArch64 JIT block linking bug. Causes crash inside of `linuxgsm` setup. +When running linuxgsm through its setup stages, it manages to crash to SIGSEGV with a branch to zero. +This is from some bug in our block linking code. + +Following the commands here: https://linuxgsm.com/servers/tfcserver/ +This can be reproduced by executing the following commands while inside of FEXBash +``` +wget -O linuxgsm.sh https://linuxgsm.sh && chmod +x linuxgsm.sh && bash linuxgsm.sh tfcserver +./tfcserver install +``` + +The second command is the one that will crash. While it works on the x86-64 JIT. + +A workaround is to change the ExitFunctionLink function to always do a dispatcher loop to the top, Arm64JITCore_ExitFunctionLink in there. But that uncovers an issue that this slows down code execution to the point that their curl instances can't download their config files in time due to timeout. + +The crash occurs in the Arm64Dispatcher.cpp in the ExitFunctionLinkerAddress asm routine. +`ldr(x3, STATE_PTR(CpuStateFrame, Pointers.Common.ExitFunctionLink));` +This LDR manages to load a nullptr +Almost feels like the CpuStateFrame is getting corrupted somehow. + +Adding Stef to this bug since they have the experience of dealing with the block linking and might see the bug quicker. diff --git a/results/scraper/fex/1878 b/results/scraper/fex/1878 new file mode 100644 index 000000000..1bea34d96 --- /dev/null +++ b/results/scraper/fex/1878 @@ -0,0 +1,8 @@ +How to proceed with building FEX-Emu inside an arm64 container (for testing) +Hello, + +I am trying to to build FEX inside a CentOS-7 aarch64 container. How do I go about this (i.e. are there sepcific compile options I need to look into)? Next I have created a CentOS-7 x86_64 chroot with all the libraries I need for running my x86_64 program, how do I tell Fex to use the chroot I made? + +If all goes well, I want to move this into my proot container as well (is FeX supported inside proot to?) + +Thanks \ No newline at end of file diff --git a/results/scraper/fex/188 b/results/scraper/fex/188 new file mode 100644 index 000000000..3af5723fe --- /dev/null +++ b/results/scraper/fex/188 @@ -0,0 +1,2 @@ +Add `HasSideEffect` to IR JSON +For the DCE pass \ No newline at end of file diff --git a/results/scraper/fex/1886 b/results/scraper/fex/1886 new file mode 100644 index 000000000..43dfcb301 --- /dev/null +++ b/results/scraper/fex/1886 @@ -0,0 +1,4 @@ +Use Fexemu run wine no sounds +I build a rootfs for FEXemu ,when i use FEXBash login in FEXBash,i run the winecfg,i mett the issue +/proc/self/exe does not point to /usr/bin/pulseaudio, cannot self execute. Are you playing games? + could you tell me how to setup pulseaudi in FEXemu rootfs. \ No newline at end of file diff --git a/results/scraper/fex/1889 b/results/scraper/fex/1889 new file mode 100644 index 000000000..e160fe0fd --- /dev/null +++ b/results/scraper/fex/1889 @@ -0,0 +1,3 @@ +Dependecies for FexLinuxTests +`sudo apt-get install gcc-multilib g++-multilib` +Add to readme and/or add install-deps target \ No newline at end of file diff --git a/results/scraper/fex/189 b/results/scraper/fex/189 new file mode 100644 index 000000000..c02542dad --- /dev/null +++ b/results/scraper/fex/189 @@ -0,0 +1,5 @@ +Annote interesting trace events +Being able to trace the application when interesting events occur is a very good thing to support. +Even if it is a "tracing" specific version to not inflict a bunch of overhead. +I learned that https://perfetto.dev/#/trace-processor.md exists. +So we can do trace profiling for getting interesting information \ No newline at end of file diff --git a/results/scraper/fex/1892 b/results/scraper/fex/1892 new file mode 100644 index 000000000..29da1d0af --- /dev/null +++ b/results/scraper/fex/1892 @@ -0,0 +1,5 @@ +Setuid binaries in FEX Rootfs +fusermount is in the rootfs and is a setuid bit binary. +We need to scan through the rootfs (automated) and delete any binaries or packages that provide these. +These won't work and need to go to the host system to be found. +Just like how we provide a log of non-existing packages inside the rootfs, provide a list of setuid binaries that we should safely remove. diff --git a/results/scraper/fex/1893 b/results/scraper/fex/1893 new file mode 100644 index 000000000..16da79f4d --- /dev/null +++ b/results/scraper/fex/1893 @@ -0,0 +1,14 @@ +Missing GL thunk function definitions +``` +template<> struct fex_gen_config<glGetVkProcAddrNV> {}; +template<> struct fex_gen_config<glPathColorGenNV> {}; +template<> struct fex_gen_config<glPathTexGenNV> {}; +template<> struct fex_gen_config<glPathFogGenNV> {}; +template<> struct fex_gen_config<glGetPathColorGenivNV> {}; +template<> struct fex_gen_config<glGetPathColorGenfvNV> {}; +template<> struct fex_gen_config<glGetPathTexGenivNV> {}; +template<> struct fex_gen_config<glGetPathTexGenfvNV> {}; +template<> struct fex_gen_config<glBlendEquationSeparateATI> {}; +``` + +Only a few missing but not sure how `glGetVkProcAddrNV` will work for us. \ No newline at end of file diff --git a/results/scraper/fex/1894 b/results/scraper/fex/1894 new file mode 100644 index 000000000..324a62a1d --- /dev/null +++ b/results/scraper/fex/1894 @@ -0,0 +1,68 @@ +Missing GLX thunk defines +``` +template<> struct fex_gen_config<glXWaitX> {}; +template<> struct fex_gen_config<glXGetGPUIDsAMD> {}; +template<> struct fex_gen_config<glXGetGPUInfoAMD> {}; +template<> struct fex_gen_config<glXGetContextGPUIDAMD> {}; +template<> struct fex_gen_config<glXCreateAssociatedContextAMD> {}; +template<> struct fex_gen_config<glXCreateAssociatedContextAttribsAMD> {}; +template<> struct fex_gen_config<glXDeleteAssociatedContextAMD> {}; +template<> struct fex_gen_config<glXMakeAssociatedContextCurrentAMD> {}; +template<> struct fex_gen_config<glXGetCurrentAssociatedContextAMD> {}; +template<> struct fex_gen_config<glXBlitContextFramebufferAMD> {}; +template<> struct fex_gen_config<glXGetCurrentDisplayEXT> {}; +template<> struct fex_gen_config<glXGetAGPOffsetMESA> {}; +template<> struct fex_gen_config<glXCreateGLXPixmapMESA> {}; +template<> struct fex_gen_config<glXReleaseBuffersMESA> {}; +template<> struct fex_gen_config<glXSet3DfxModeMESA> {}; +template<> struct fex_gen_config<glXCopyBufferSubDataNV> {}; +template<> struct fex_gen_config<glXNamedCopyBufferSubDataNV> {}; +template<> struct fex_gen_config<glXCopyImageSubDataNV> {}; +template<> struct fex_gen_config<glXDelayBeforeSwapNV> {}; +template<> struct fex_gen_config<glXEnumerateVideoDevicesNV> {}; +template<> struct fex_gen_config<glXBindVideoDeviceNV> {}; +template<> struct fex_gen_config<glXJoinSwapGroupNV> {}; +template<> struct fex_gen_config<glXBindSwapBarrierNV> {}; +template<> struct fex_gen_config<glXQuerySwapGroupNV> {}; +template<> struct fex_gen_config<glXQueryMaxSwapGroupsNV> {}; +template<> struct fex_gen_config<glXQueryFrameCountNV> {}; +template<> struct fex_gen_config<glXResetFrameCountNV> {}; +template<> struct fex_gen_config<glXBindVideoCaptureDeviceNV> {}; +template<> struct fex_gen_config<glXEnumerateVideoCaptureDevicesNV> {}; +template<> struct fex_gen_config<glXLockVideoCaptureDeviceNV> {}; +template<> struct fex_gen_config<glXQueryVideoCaptureDeviceNV> {}; +template<> struct fex_gen_config<glXReleaseVideoCaptureDeviceNV> {}; +template<> struct fex_gen_config<glXGetVideoDeviceNV> {}; +template<> struct fex_gen_config<glXReleaseVideoDeviceNV> {}; +template<> struct fex_gen_config<glXBindVideoImageNV> {}; +template<> struct fex_gen_config<glXReleaseVideoImageNV> {}; +template<> struct fex_gen_config<glXSendPbufferToVideoNV> {}; +template<> struct fex_gen_config<glXGetVideoInfoNV> {}; +template<> struct fex_gen_config<glXQueryHyperpipeNetworkSGIX> {}; +template<> struct fex_gen_config<glXHyperpipeConfigSGIX> {}; +template<> struct fex_gen_config<glXQueryHyperpipeConfigSGIX> {}; +template<> struct fex_gen_config<glXDestroyHyperpipeConfigSGIX> {}; +template<> struct fex_gen_config<glXBindHyperpipeSGIX> {}; +template<> struct fex_gen_config<glXQueryHyperpipeBestAttribSGIX> {}; +template<> struct fex_gen_config<glXHyperpipeAttribSGIX> {}; +template<> struct fex_gen_config<glXQueryHyperpipeAttribSGIX> {}; +template<> struct fex_gen_config<glXBindSwapBarrierSGIX> {}; +template<> struct fex_gen_config<glXQueryMaxSwapBarriersSGIX> {}; +template<> struct fex_gen_config<glXJoinSwapGroupSGIX> {}; +template<> struct fex_gen_config<glXBindChannelToWindowSGIX> {}; +template<> struct fex_gen_config<glXChannelRectSGIX> {}; +template<> struct fex_gen_config<glXQueryChannelRectSGIX> {}; +template<> struct fex_gen_config<glXQueryChannelDeltasSGIX> {}; +template<> struct fex_gen_config<glXChannelRectSyncSGIX> {}; +template<> struct fex_gen_config<glXCushionSGI> {}; +template<> struct fex_gen_config<glXGetTransparentIndexSUN> {}; +template<> struct fex_gen_config<glXBindTexImageARB> {}; +template<> struct fex_gen_config<glXReleaseTexImageARB> {}; +template<> struct fex_gen_config<glXDrawableAttribARB> {}; +template<> struct fex_gen_config<glXGetFrameUsageMESA> {}; +template<> struct fex_gen_config<glXBeginFrameTrackingMESA> {}; +template<> struct fex_gen_config<glXEndFrameTrackingMESA> {}; +template<> struct fex_gen_config<glXQueryFrameTrackingMESA> {}; +``` + +A fair number of these missing from glxext.h \ No newline at end of file diff --git a/results/scraper/fex/1903 b/results/scraper/fex/1903 new file mode 100644 index 000000000..6ccf1b149 --- /dev/null +++ b/results/scraper/fex/1903 @@ -0,0 +1,2 @@ +Guarantee Fork Safety +Setup rules, write tests & docs, enforce them, provide a guest model \ No newline at end of file diff --git a/results/scraper/fex/1905 b/results/scraper/fex/1905 new file mode 100644 index 000000000..1b4f34800 --- /dev/null +++ b/results/scraper/fex/1905 @@ -0,0 +1,5 @@ +Migrate to GitHub Discussions +- Add https://github.com/FEX-Emu/FEX/discussions to fex-emu.org +- Move discussion, questions, ugc tickets to discussion +- Direct users towards discussions, instead of the issue tracker +- Integrate with discord \ No newline at end of file diff --git a/results/scraper/fex/1909 b/results/scraper/fex/1909 new file mode 100644 index 000000000..30e65426a --- /dev/null +++ b/results/scraper/fex/1909 @@ -0,0 +1,4 @@ +Modify Front/Middle/Back Ends to use pooled storage, for efficiency and recursion +Can pool +- Process wide +- System wide \ No newline at end of file diff --git a/results/scraper/fex/1910 b/results/scraper/fex/1910 new file mode 100644 index 000000000..eb7429edd --- /dev/null +++ b/results/scraper/fex/1910 @@ -0,0 +1,16 @@ +New Register Allocator +Migrating from SSA to SVD/local-SSA/GVN + +Targets: +- Improved Code Gen (#87) +- Vastly reduced complexity +- Linear, parellisable allocation (#85) +- Native support for flexible SRA (#608, #609, #610, #611) +- Support context reconstruction and midway exit and multiple entry points (#607, [skmp/multiple-entry-points](https://github.com/FEX-Emu/FEX/commits/skmp/multiple-entry-points)) +- https://github.com/FEX-Emu/FEX/issues/1717 +- https://github.com/FEX-Emu/FEX/issues/1655 + +Wishes +- Better partial allocations +- Native support for separate vregs and pregs +- #1791 \ No newline at end of file diff --git a/results/scraper/fex/1911 b/results/scraper/fex/1911 new file mode 100644 index 000000000..0adefeea6 --- /dev/null +++ b/results/scraper/fex/1911 @@ -0,0 +1,4 @@ +Reorganize FEX source +Many things are named inconsistently, and others are too complex. + +Simplify \ No newline at end of file diff --git a/results/scraper/fex/1912 b/results/scraper/fex/1912 new file mode 100644 index 000000000..cf56a8122 --- /dev/null +++ b/results/scraper/fex/1912 @@ -0,0 +1,16 @@ +Rework glue (Context / Dispatch / Translation / Lookup Cache) interfaces and structures +Tackle at least + +- #612 +- #806 +- #807 +- #808 +- #835 +- #1035 +- #1511 +- #1654 +- #1675 +- #1772 +- #1780 + +And also deduplicate code around them \ No newline at end of file diff --git a/results/scraper/fex/1913 b/results/scraper/fex/1913 new file mode 100644 index 000000000..72ab2cdd2 --- /dev/null +++ b/results/scraper/fex/1913 @@ -0,0 +1,2 @@ +Add support for transparent aarch64 simulation with x86 host +Do test SVE and other stuff. \ No newline at end of file diff --git a/results/scraper/fex/1918 b/results/scraper/fex/1918 new file mode 100644 index 000000000..dab15edef --- /dev/null +++ b/results/scraper/fex/1918 @@ -0,0 +1,2 @@ +Change Guest Build System to use chroot headers for x86 +Follow up from #1891 #1902 \ No newline at end of file diff --git a/results/scraper/fex/1921 b/results/scraper/fex/1921 new file mode 100644 index 000000000..d10acf5ad --- /dev/null +++ b/results/scraper/fex/1921 @@ -0,0 +1,14 @@ +4k page emulation +Splitting from #1221 + +from @skmp +> We now have a fairly clean interface - one would need to add support for this in virtual void `GuestMmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset) = 0;` and `GuestMunmap`, and maybe introduce a `GuestMprotect` and then it would all work. + +from @marcan +> mmap on files can be made to work perfectly fine as long as the vaddr is not requested as fixed. You just align the mapping to 16K and give the app an offset halfway into the page if needed. munmap would then align back before unmapping the 16K aligned block. + +> mprotect similarly would only fail if the app is trying to do its own page management at page granularity. Many uses of mprotect are used on whatever mmap returned, and since that would be 16K aligned (or the above hack for file maps), it could similarly be made to work. + +We are already tracking guest VMAs for mtrack, so adding the few extra things needed should be fairly uneventful. + +I'm putting it in the 2212 milestone, hopefully the asahi side is ready by then. \ No newline at end of file diff --git a/results/scraper/fex/1922 b/results/scraper/fex/1922 new file mode 100644 index 000000000..d90d8a28b --- /dev/null +++ b/results/scraper/fex/1922 @@ -0,0 +1,3 @@ +Proton Experimental games broken on AArch64 +Something changed somewhere and now they are broken again. +They cause a SIGQUIT fairly early after creating their window. \ No newline at end of file diff --git a/results/scraper/fex/1923 b/results/scraper/fex/1923 new file mode 100644 index 000000000..4103f11ea --- /dev/null +++ b/results/scraper/fex/1923 @@ -0,0 +1,9 @@ +Guest thunks compiled twice +The cosmetic cmake include for IDEs somehow makes it to the build + +``` + # Thunk targets for IDE integration of guest code, only + add_subdirectory(ThunkLibs/GuestLibs) +``` + +This makes guest thunk take twice as long to compile \ No newline at end of file diff --git a/results/scraper/fex/1925 b/results/scraper/fex/1925 new file mode 100644 index 000000000..2edc8458f --- /dev/null +++ b/results/scraper/fex/1925 @@ -0,0 +1,2 @@ +Containerize our CI +So that compiles run in a known environment with full control over packages that can be replicated in any dev host \ No newline at end of file diff --git a/results/scraper/fex/1930 b/results/scraper/fex/1930 new file mode 100644 index 000000000..77abaa124 --- /dev/null +++ b/results/scraper/fex/1930 @@ -0,0 +1,7 @@ +64-bit VDSO +Similar to #690 but actually matters. +I've noticed with a lot of proton games that abuse `clock_gettime(CLOCK_MONOTONIC` very heavily, Calling it roughly every 51 MICROSECONDS! Considering the syscall itself can take 16-100 microseconds, this takes a wackload of time relatively. + +Implementing VDSO so we can forward it to AArch64 VDSO to save cycles will give proton a significant performance boost. + +I'll give this an implement since I've already spent time looking at the VDSO ELF format and what it takes to wire this up. \ No newline at end of file diff --git a/results/scraper/fex/1933 b/results/scraper/fex/1933 new file mode 100644 index 000000000..54de63759 --- /dev/null +++ b/results/scraper/fex/1933 @@ -0,0 +1,3 @@ +48-bit VA breaks proton 7.0 +Just noticed this in my testing, I wasn't running 48-bit for a while so I didn't notice this being broken. +Works with 36-bit VA but not 48-bit \ No newline at end of file diff --git a/results/scraper/fex/1934 b/results/scraper/fex/1934 new file mode 100644 index 000000000..db94cf36f --- /dev/null +++ b/results/scraper/fex/1934 @@ -0,0 +1,5 @@ +Use EXCLUDE_FROM_ALL to make targets optional in CMake +Follow up from #1926 +`set_target_properties(MyTarget PROPERTIES EXCLUDE_FROM_ALL TRUE)` + +Should also be done to other targets, like the IDE ones for thunks. #1923 \ No newline at end of file diff --git a/results/scraper/fex/1935 b/results/scraper/fex/1935 new file mode 100644 index 000000000..d542c4bb7 --- /dev/null +++ b/results/scraper/fex/1935 @@ -0,0 +1,9 @@ +Rework frequently used anti-patterns in the codebase +Some commonly used anti-patterns that make our lifes harder while working with FEX +- Re-use of class names with different namespaces (makes navigation, search and replace, debugging hard) +- Overly, inconsistently namespaced codebase +- File names that don't match the class name, or missmatching .h/.cpp file names +- Inline forward declarations in header files +- Inconsistent grouping of helper libs + +These should all be addressed. \ No newline at end of file diff --git a/results/scraper/fex/1936 b/results/scraper/fex/1936 new file mode 100644 index 000000000..7f509eda3 --- /dev/null +++ b/results/scraper/fex/1936 @@ -0,0 +1,4 @@ +Caches: Investigating adding some form of balancing in the BST +Index trees are constructed without any form of balancing. + +Follow up from #1842 \ No newline at end of file diff --git a/results/scraper/fex/1937 b/results/scraper/fex/1937 new file mode 100644 index 000000000..e9c9b8e03 --- /dev/null +++ b/results/scraper/fex/1937 @@ -0,0 +1,4 @@ +Code Caches: Investigate adding a sorted array mode if the BSTs are not dirty +Currently the indexes are handled as BSTs, we could handle them as sorted array when they are not modified + +Follow up from #1842 \ No newline at end of file diff --git a/results/scraper/fex/1938 b/results/scraper/fex/1938 new file mode 100644 index 000000000..54bcc673b --- /dev/null +++ b/results/scraper/fex/1938 @@ -0,0 +1,4 @@ +Code Caches: Fully postfix cache folders with compilation modal options +Currently only a few mode bits are captured in #1842. This should be done in a more uniform and complete way. + +Follow up from #1842 \ No newline at end of file diff --git a/results/scraper/fex/1939 b/results/scraper/fex/1939 new file mode 100644 index 000000000..04fbef79a --- /dev/null +++ b/results/scraper/fex/1939 @@ -0,0 +1,4 @@ +Object Code Caches: Generate relocations in relocation pools, import cached files directly to code cache +Relocation pools can be marked MAP_PRIVATE instead of MAP_SHARED, and as such the object code caches can be used as is for execution instead of having to be imported to the per thread tcb. + +Follow up from #1842 \ No newline at end of file diff --git a/results/scraper/fex/1943 b/results/scraper/fex/1943 new file mode 100644 index 000000000..116982a2f --- /dev/null +++ b/results/scraper/fex/1943 @@ -0,0 +1,33 @@ +re-introduce wrapping structs for syscall registration +Recently, a PR removed this, and broke useful backtraces for debugging +``` +Switching to thread 2 (Thread 0x7fff5eac7640 (LWP 1501682))] +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +38 ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory. +(gdb) bt +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x0000555555ab6a1a in FEX::HLE::x64::RegisterThread(FEX::HLE::SyscallHandler*)::$_1::operator()(FEXCore::Core::CpuStateFrame*, int*, int, int, timespec const*, int*, unsigned int) const ( + this=0x7ffff76c29b0, Frame=0x7ffff76c29b0, uaddr=0x7fffdec171d8, futex_op=128, val=10, timeout=0x0, uaddr2=0x7fffdec171c0, val3=3737219520) + at /home/skmp/projects/FEX/Source/Tests/LinuxSyscalls/x64/Thread.cpp:59 +#2 0x0000555555ab69c8 in FEX::HLE::x64::RegisterThread(FEX::HLE::SyscallHandler*)::$_1::__invoke(FEXCore::Core::CpuStateFrame*, int*, int, int, timespec const*, int*, unsigned int) ( + Frame=0x7ffff76c29b0, uaddr=0x7fffdec171d8, futex_op=128, val=10, timeout=0x0, uaddr2=0x7fffdec171c0, val3=3737219520) at /home/skmp/projects/FEX/Source/Tests/LinuxSyscalls/x64/Thread.cpp:59 +#3 0x0000555555a2b90c in std::__invoke_impl<unsigned long, unsigned long (*&)(FEXCore::Core::CpuStateFrame*, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long), FEXCore::Core::CpuStateFrame*&, unsigned long&, unsigned long&, unsigned long&, unsigned long&, unsigned long&, unsigned long&> ( + __f=@0x7ffff76e32f8: 0x555555ab6980 <FEX::HLE::x64::RegisterThread(FEX::HLE::SyscallHandler*)::$_1::__invoke(FEXCore::Core::CpuStateFrame*, int*, int, int, timespec const*, int*, unsigned int)>, + __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552, + __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552) + at /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:61 +#4 0x0000555555a2b819 in std::__invoke<unsigned long (*&)(FEXCore::Core::CpuStateFrame*, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long), FEXCore::Core::CpuStateFrame*&, unsigned long&, unsigned long&, unsigned long&, unsigned long&, unsigned long&, unsigned long&> ( + __fn=@0x7ffff76e32f8: 0x555555ab6980 <FEX::HLE::x64::RegisterThread(FEX::HLE::SyscallHandler*)::$_1::__invoke(FEXCore::Core::CpuStateFrame*, int*, int, int, timespec const*, int*, unsigned int)>, + __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552, + __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552) + at /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/invoke.h:96 +#5 0x0000555555a2a009 in std::invoke<unsigned long (*&)(FEXCore::Core::CpuStateFrame*, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long), FEXCore::Core::CpuStateFrame*&, unsigned long&, unsigned long&, unsigned long&, unsigned long&, unsigned long&, unsigned long&> ( + __fn=@0x7ffff76e32f8: 0x555555ab6980 <FEX::HLE::x64::RegisterThread(FEX::HLE::SyscallHandler*)::$_1::__invoke(FEXCore::Core::CpuStateFrame*, int*, int, int, timespec const*, int*, unsigned int)>, + __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552, + __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552, __args=@0x7fff5eac4950: 140736930607552) + at /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/functional:97 +#6 0x0000555555a23e65 in FEX::HLE::SyscallHandler::HandleSyscall (this=0x7ffff76ba000, Frame=0x7ffff76c29b0, Args=0x7fff5eac4920) at /home/skmp/projects/FEX/Source/Tests/LinuxSyscalls/Syscalls.cpp:762 +#7 0x000055555567b41e in FEXCore::Context::HandleSyscall (Handler=0x7ffff76ba000, Frame=0x7ffff76c29b0, Args=0x7fff5eac4920) + at /home/skmp/projects/FEX/External/FEXCore/Source/Interface/Core/Core.cpp:1463 + +``` \ No newline at end of file diff --git a/results/scraper/fex/1951 b/results/scraper/fex/1951 new file mode 100644 index 000000000..bd06c9335 --- /dev/null +++ b/results/scraper/fex/1951 @@ -0,0 +1,9 @@ +Proton Crash in both experimental, 7.0-4 and other versions +When running games through Steam via Proton, the game crashes without giving any proper error message. Last message returned before exiting: + +`Game process removed: AppID 322170 "/home/odin/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=322170 -- '/home/odin/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier'/_v2-entry-point --verb=waitforexitandrun -- 'home/odin/.local/share/Steam/steamapps/common/Proton 7.0'/proton waitforexitandrun '/home/odin/.local/share/Steam/steamapps/common/Geometry Dash/GeometryDash.exe'", ProcID 4847` + +This error message is virtually the same when running different Proton versions and different games (games tested: Geometry Dash, Arietta of Spirits, Final Fantasy 7, Sayonara Wild Hearts). Linux Native games work without issue. + +Device: AYN Odin Pro +uname -a: Linux valhalla 5.18.3-odin-arm64 #5 SMP PREEMPT Wed Jul 13 14:36:06 WIB 2022 aarch64 GNU/Linux \ No newline at end of file diff --git a/results/scraper/fex/1952 b/results/scraper/fex/1952 new file mode 100644 index 000000000..6fd672d7a --- /dev/null +++ b/results/scraper/fex/1952 @@ -0,0 +1,8 @@ +Make sure IR dump / parser still round trips correctly +Dump shows like +``` + %ssa18 i64 = EntrypointOffset #0x32, u8:Tmp:RegisterSize + (%ssa19 i64) Break %ssa18 i64, {0.11.0.128} +``` + +The paser can't parse this \ No newline at end of file diff --git a/results/scraper/fex/1953 b/results/scraper/fex/1953 new file mode 100644 index 000000000..e663af37f --- /dev/null +++ b/results/scraper/fex/1953 @@ -0,0 +1,7 @@ +Rework configuration system +- Missmatching argument vs env values +- Two layers of mappings that we don't really need to go through +- Factor common code out of FEXLoader, IRLoader, TestHarness, etc +- Add command line option to ignore any other layers (for CI, tests) +- Don't flatten default values / provide specific default values (possibly "default?") for easier config migrations +- Add configuration versioning for future automatic config migration \ No newline at end of file diff --git a/results/scraper/fex/1954 b/results/scraper/fex/1954 new file mode 100644 index 000000000..6c06542f9 --- /dev/null +++ b/results/scraper/fex/1954 @@ -0,0 +1,5 @@ +Add code cache viewers +- Inspect/Visualise index fixes +- Inspect code caches +- Show IR disasm +- Show OBJ disasm \ No newline at end of file diff --git a/results/scraper/fex/1955 b/results/scraper/fex/1955 new file mode 100644 index 000000000..d7707ce7b --- /dev/null +++ b/results/scraper/fex/1955 @@ -0,0 +1,7 @@ +Cleanup Arm64 backend GetSrc/GetReg/... +`GetReg<RA_32>` for i32 +`GetReg<RA_64>` for i64 +`GetSrc` for FPR +`GetSrcPair` for FPR pairs? + +We need a uniform way, across all backends, for RA to work \ No newline at end of file diff --git a/results/scraper/fex/1956 b/results/scraper/fex/1956 new file mode 100644 index 000000000..cd595e88c --- /dev/null +++ b/results/scraper/fex/1956 @@ -0,0 +1,7 @@ +SMC: Finer grained Mman / Invalidation Locks +Follow up from #1842, + +We can use much finer grained mman / translation locks, vs the lock the world approach taken there. + +- Use an inverval lock tree +- Lock based on arguments (eg, mmap w/o MAP_FIXED doesn't need to clear code caches, or mprotect that doesn't affect PROT_EXEC, etc) \ No newline at end of file diff --git a/results/scraper/fex/1957 b/results/scraper/fex/1957 new file mode 100644 index 000000000..31f3f2509 --- /dev/null +++ b/results/scraper/fex/1957 @@ -0,0 +1,8 @@ +Driver: Check for PROT_EXEC on translation, gracefully handle SIGBUS +Currently we'll happily translate pages without PROT_EXEC or not mapped at all. + +We need to only permit code to run in guest mapped pages, and only ones with PROT_EXEC, or appropriately generate SIGSEGVs for the guest. + +We also need to gracefully handle SIGBUSes during translation, eg from PROT_EXEC mappings that are out of range. + +We also need FLTs for those. \ No newline at end of file diff --git a/results/scraper/fex/1958 b/results/scraper/fex/1958 new file mode 100644 index 000000000..09dd7b8be --- /dev/null +++ b/results/scraper/fex/1958 @@ -0,0 +1,4 @@ +Run FTLs with Code Caches as part of tests +Follow up from #1842. + +Also make sure caching passes the smc tests and handles anonymous fds, etc. \ No newline at end of file diff --git a/results/scraper/fex/1959 b/results/scraper/fex/1959 new file mode 100644 index 000000000..2777da455 --- /dev/null +++ b/results/scraper/fex/1959 @@ -0,0 +1,4 @@ +Validate thunk relocations work with OBJCache +... and also add FLTs for that. + +Follow up from #1842 \ No newline at end of file diff --git a/results/scraper/fex/1960 b/results/scraper/fex/1960 new file mode 100644 index 000000000..9a5a605fd --- /dev/null +++ b/results/scraper/fex/1960 @@ -0,0 +1,15 @@ +Built in Debugger: Rework interfaces, make sure things work +Currently the Visual Debugger is non functional, and it depends on debug interfaces that are no longer implemented and miss features like multiple thread support. + +A large part of those interfaces was disabled in #1842. + +We need to +#### Milestone 2210 +- Define a fuller, actually implemented debug interface +- Add tests for that interface + +#### Milestone 2212 +- Update the visual debugger & gdb shims to use those interfaces, or make a decision to remove the visual debugger / gdb shim +- If we keep the visual debugger / gdb shims, make sure they are built and tested. + +Follow up from #1842 \ No newline at end of file diff --git a/results/scraper/fex/1961 b/results/scraper/fex/1961 new file mode 100644 index 000000000..db41403cd --- /dev/null +++ b/results/scraper/fex/1961 @@ -0,0 +1,7 @@ +Implement whole page hashing and page versioning +This will enable us to +- Avoid rehashing pages for Code Caches +- Better track SMC +- Open a way for PROT_EXEC page deduplication in the future + +Follow up from #1842 \ No newline at end of file diff --git a/results/scraper/fex/1962 b/results/scraper/fex/1962 new file mode 100644 index 000000000..dbca6d2bd --- /dev/null +++ b/results/scraper/fex/1962 @@ -0,0 +1,4 @@ +Code Cache: Don't hold advisory locks during DATA updates / resizes +... should reduce stutter contention + +Follow up from #1842 \ No newline at end of file diff --git a/results/scraper/fex/1963 b/results/scraper/fex/1963 new file mode 100644 index 000000000..dfbd17e75 --- /dev/null +++ b/results/scraper/fex/1963 @@ -0,0 +1,6 @@ +Code Caching: Track pages before hashing +.. to avoid a race condition around stale caches. + +Possibly best implemented via #1961 + +Follow up from #1842 \ No newline at end of file diff --git a/results/scraper/fex/1964 b/results/scraper/fex/1964 new file mode 100644 index 000000000..9d4d81eed --- /dev/null +++ b/results/scraper/fex/1964 @@ -0,0 +1,7 @@ +Code Caches Cleanups +There's quite a bit of cruft in core.cpp and other files, that is best tackled as a follow up because of interdependencies with other open PRs. + +- Better code reuse between IR and OBJ driver logic, currently it is copy paste +- Full compile mode namespacing for cache files + +Follow up from #1842 \ No newline at end of file diff --git a/results/scraper/fex/1965 b/results/scraper/fex/1965 new file mode 100644 index 000000000..a326f752e --- /dev/null +++ b/results/scraper/fex/1965 @@ -0,0 +1,31 @@ +Project power grab +Hello ya all, + + + +I consider this to be schemed by @Sonicadvance1, as @phire has minimal commits to the project, and hasn't been active in a very long time. + +To give some context, I internally raised some issues wrt to @neobrain's conduct, then the next meeting was canceled a few hours before because @Sonicadvance1 "had to travel", then my admin rights in fex-emu.org google workspace were somehow missing, and not willing to be re-instanted, and while I was blissfully working on some other things I saw this. + +Even though my access to the discord server was removed, I've kept logs of my original complaint, as well as the (several pages) of discussion that followed with @phire. + +@Sonicadvance1 and @neobrain didn't participate at all for days. + +In order to prevent the spreading of further misinformation, and in my defence towards https://fex-emu.com/Uncomfortable-decision/ and https://twitter.com/FEX_Emu/status/1565334640423948288, I'll be redirecting fex-emu.org to a more neutral page. + +I would like to state here, I was given no time to appeal the process or advance knowledge before the public posts, which is indicative of a power grab, as I didn't have any chance to review the accusations, defend myself or bring forth evidence. + +While fex-emu was supposed to be a collective / consensus based project, at least in discussions, in practice there had been a lack of transparency in communications and a clear internal hierarchy established, with @Sonicadvance1 not sharing information with the other "maintainers". + +I'm asking of everyone involved, to take a mediation step and try to resolve this, and to discuss everything in public, so long as we are not contractually bound not to do so, as to avoid behind the scenes scheming. + +I guess I'll update this ticket with further information? + +Not sure if I'm still a member of the github org, but if so I'll be removing myself as I'm clearly not welcome here. + + +**update** +Of course i've been removed, it's a proper power grab ;) + +**update 2** +https://fex-emu.org/ now has a banner linking to this issue, and an iframe of fex-emu.com after that \ No newline at end of file diff --git a/results/scraper/fex/1967 b/results/scraper/fex/1967 new file mode 100644 index 000000000..b5f1fe667 --- /dev/null +++ b/results/scraper/fex/1967 @@ -0,0 +1,55 @@ +Can't execute FEXRootFSFetcher and sometimes can't compile FEX(in termux) +I use termux to execute that command + +When i execute the FEXRootFSFetcher. It can't be executed and print "terminate called after throwing an instance of + 'std::out_of_range' what(): basic_string::at: __n (which is 0) >= this->size() (which is 0)" +I don't know the command that why it can't be executed . +Sometimes I compile FEX，the compile program offten throw compile error. it's strange + +**System information:** + - OS: Android 12 + - terminal:termux(0.118.0) + - CPU/SoC: MTK8100(rubens) + - Video driver version: openGl 4.5 (Compatibility Profile) Mesa 22.1.7 + - RootFS used: Ubuntu Kinetic Kudu (development branch) aarch64 + - FEX version: FEX-2208-45-g12fee91 + - Thunks Enabled: no + +**To Reproduce** +1.sudo apt install cmake make ninja-build clang libglfw3-dev libsdl2-dev libepoxy-dev g++-x86-64-linux-gnu nasm squashfuse squashfs-tools +2. git clone https://github.com/FEX-Emu/FEX.git && git submodule update --init +3. mkdir build && cd build +4.CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DENABLE_LTO=True -DBUILD_TESTS=False -G Ninja .. +5. error: +CMake Error at /lib/aarch64-linux-gnu/cmake/SDL2/sdl2-config.cmake:13 (message): + File or directory //include/SDL2 referenced by variable SDL2_INCLUDE_DIR + does not exist ! + Call Stack (most recent call first): + /lib/aarch64-linux-gnu/cmake/SDL2/sdl2-config.cmake:27 (set_and_check) + Source/Tools/FEXConfig/CMakeLists.txt:7 (find_package) + +6.more details of error: + Run Build Command(s):/bin/ninja cmTC_6413d && [1/2] Building C object + CMakeFiles/cmTC_6413d.dir/HAVE_GDB_JIT_READER_H.c.o + FAILED: CMakeFiles/cmTC_6413d.dir/HAVE_GDB_JIT_READER_H.c.o + /bin/clang -MD -MT CMakeFiles/cmTC_6413d.dir/HAVE_GDB_JIT_READER_H.c.o -MF + CMakeFiles/cmTC_6413d.dir/HAVE_GDB_JIT_READER_H.c.o.d -o CMakeFiles/cmTC_6413d.dir/HAVE_GDB_JIT_READER_H.c.o -c + /root/FEX/build/CMakeFiles/CheckIncludeFiles/HAVE_GDB_JIT_READER_H.c + /root/FEX/build/CMakeFiles/CheckIncludeFiles/HAVE_GDB_JIT_READER_H.c:2:10: fatal error: 'gdb/jit-reader.h' file not found + #include <gdb/jit-reader.h> + ^~~~~~~~~~~~~~~~~~ + 1 error generated. + ninja: build stopped: subcommand failed. + + Source: + /* */ + #include <gdb/jit-reader.h> + + int main(void) + { + return 0 + ;} + +Please tell me what i should do to solve the problem +The last one is your wiki website could't be visited and i can't get help in time +Have a good day \ No newline at end of file diff --git a/results/scraper/fex/1972 b/results/scraper/fex/1972 new file mode 100644 index 000000000..4ff944680 --- /dev/null +++ b/results/scraper/fex/1972 @@ -0,0 +1,6 @@ +Consider using Catch2 in FEXLinuxTests +Current FEXLinuxTests are limited to binary test results ("does it run without crashes?") and manual inspection of test logs. Catch2 allows for structured testing, where several properties can be tested independendly, each of which is highlighted explicitly with a REQUIRES macro. Catch2's automatic test discovery could also help clean up the build system logic. + +> If we are going to implement catch2 in the FEXLinuxTests then it should be an indepedent task from this PR. No need to complicate this PR with changing test behaviours here. + +_Originally posted by @Sonicadvance1 in https://github.com/FEX-Emu/FEX/pull/1941#discussion_r962034993_ \ No newline at end of file diff --git a/results/scraper/fex/198 b/results/scraper/fex/198 new file mode 100644 index 000000000..2cfd95ca6 --- /dev/null +++ b/results/scraper/fex/198 @@ -0,0 +1,26 @@ +Failing ARM tests +These failures happen on ARM only. Will disable them for merge, bu opening a ticket so we follow up on them + +# conformance-interfaces-fsync-4-1.test.jit.posix (jit only) +Looks like an actual JIT bug +``` +2020-05-23T19:29:12.3407909Z 4976: timeout: the monitored command dumped core +2020-05-23T19:29:12.3419427Z 4976: test failed, expected is 0 but got -11 +``` + +# conformance-interfaces-mmap-21-1.test.int.posix (int and jit fail the same way) +The test passes, while it fails for x86 (native, x86 emulator). Not sure this is a bug yet. +``` +2020-05-23T19:29:30.5500586Z 5043: Test PASS: mmap/21-1.c Error at mmap: Invalid argument +2020-05-23T19:29:30.5515182Z 5043: [DEBUG] Reason we left VM: 3 +2020-05-23T19:29:30.5546797Z 5043: [DEBUG] Managed to load? No +2020-05-23T19:29:30.5619388Z 5043: test failed, expected is 1 but got 0 +``` + +# conformance-interfaces-mmap-31-1.test.int.posix (jit and int fail the same way) +The test passes, while it fails for x86 (native, x86 emulator). Not sure this is a bug yet. +``` +2020-05-23T19:29:30.5762072Z 5049: off: fffffffffffff000, len: fffffffffffff000 +2020-05-23T19:29:30.5765496Z 5049: Test Pass: mmap/31-1.c Error at mmap: Value too large for defined data type +2020-05-23T19:29:30.5778912Z 5049: [DEBUG] Reason we left VM: 3 +``` \ No newline at end of file diff --git a/results/scraper/fex/1980 b/results/scraper/fex/1980 new file mode 100644 index 000000000..76a311c7c --- /dev/null +++ b/results/scraper/fex/1980 @@ -0,0 +1,4 @@ +FEXLinuxTests: SIGFPE not raised in ./synchronous-signal-block.64 +`./synchronous-signal-block.64 sfpe` and `./synchronous-signal-block.64 afpe` should print `Got 8 at address: ...` since they're triggering a SIGFPE. However, when running these tests in FEXInterpreter, that doesn't seem to be the case. + +I have not ran those tests on an x86 host yet, so it's unclear if the bug is in FEX or in the test. diff --git a/results/scraper/fex/1994 b/results/scraper/fex/1994 new file mode 100644 index 000000000..a37ab08b7 --- /dev/null +++ b/results/scraper/fex/1994 @@ -0,0 +1,6 @@ +Resolve VIXL simulator narrowing/widening bugs +Neoverse-V2 was announced today: https://www.anandtech.com/show/17575/arm-announces-neoverse-v2-and-e2-the-next-generation-of-arm-server-cpu-cores + +As far as we can tell it looks like they reduced the SVE register size from 256-bit to 128-bit. This means our use of the vixl simulator is going to be used quite a bit longer than expected. + +We should solve the issues in the simulator for the couple of failing tests so we don't trip over them in the future. At least until we have real SVE 256-bit hardware in CI. \ No newline at end of file diff --git a/results/scraper/fex/1996 b/results/scraper/fex/1996 new file mode 100644 index 000000000..10b9270eb --- /dev/null +++ b/results/scraper/fex/1996 @@ -0,0 +1,39 @@ +Build thunks GuestLibs on other arm64 distros (say, Arch Linux) +Currently we rely on debian's `gcc-x86-64-linux-gnu` package to supply a working x86_64 cross-compiler on Debian/Ubuntu distros. But other distros (like Arch Linux) are missing such handy packages. + +I've done a bit of preliminary research, and it seems like these are our rough options: + +### Option One - Use clang instead: + +Clang helpfully includes compilers for all triples by default, and cross-compiling is simply a matter of passing the correct triple into clang/clang++. This seems like an elegant solution, we already require clang for thunk generation, why not use it for building thunks too. + +However... This solution *only* gets you a compiler. +The `gcc-x86-64-linux-gnu` package (and the `g++`/`multilib-i686` variants) actually pull in a bunch of other packages to supply a full libc and libc++ and other support libraries that our thunks need to build. If we go with the clang option, then we need to supply the missing include from somewhere else. + +But from where? We have a two potential options: + + * Most of the include files can be found in the host, though we will need to supply the missing x86 bits of linux headers, glibc and libstdc++. + * This option runs the risk that other random libraries will change their include files slightly depending on host arch, and might end up doing the wrong thing + * We will be missing the .so files, can we create our thunks without them? + * We just supply all the includes, either: + * a rootfs style download (generated along-side our rootfs? That would keep them in-sync) + * as a submodule + +### Option Two - Generate equivalent packages for Arch + +These packages are clearly useful for Debian, would be nice to have equivalents in Arch Linux ARM. + +There are some downsides to this approach: + + 1. these packages will be in AUR and will take a while to build from source (especially if people are building them on lower-end ARM SBCs, maybe we could supply equivalent binary packages?) + 2. We would need to maintain them + 3. It only fixes the issue for Arch Linux ARM and derivatives; Other distros still won't be able to build thunks. + +### Idea three - Just use a native x86 toolchain inside our rootfs + +This is an ugly and lazy option. Requires a large download (and probably unpacking the rootfs to install a compiler) + +------ + + +Whatever solution we go with, we should standardise across all distros, so we aren't using widely different approaches on different distros. I'm currently leaning towards Option One, with us packaging headers, not just for libc/libstdc++, but all libraries we thunk. \ No newline at end of file diff --git a/results/scraper/fex/2020 b/results/scraper/fex/2020 new file mode 100644 index 000000000..e477e00aa --- /dev/null +++ b/results/scraper/fex/2020 @@ -0,0 +1 @@ +Tests: `clock_nanosleep_test.jit.gvisor` needs to be added to flakes diff --git a/results/scraper/fex/2021 b/results/scraper/fex/2021 new file mode 100644 index 000000000..ee8ebcbb2 --- /dev/null +++ b/results/scraper/fex/2021 @@ -0,0 +1,22 @@ +32-bit wine-mono hangs on call to Math.Sin +Very specific one, + +Application will hang when running a .NET Framework 32-bit application under wine (using wine-mono) if that application calls Math.Sin/Math.Cos. Other functions work. + +Precompiled .exe binary here: + +[CallumSinCos.zip](https://github.com/FEX-Emu/FEX/files/9653755/CallumSinCos.zip) + +C# source: + +```cs +using System; +class Program +{ + static void Main(string[] args) + { + Console.WriteLine("Sin {0}", Math.Sin(Math.PI)); + Console.WriteLine("Cos {0}", Math.Cos(Math.PI)); + } +} +``` diff --git a/results/scraper/fex/2031 b/results/scraper/fex/2031 new file mode 100644 index 000000000..555aaaabf --- /dev/null +++ b/results/scraper/fex/2031 @@ -0,0 +1,13 @@ +FTL crashes when using GL thunks without GLVND +Running the game using a mesa build with GLVND disabled triggers a crash on startup: +``` +Thread 1 "FEXInterpreter" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7ff7ff1010 (LWP 7822)] +0x0000000000000000 in ?? () +(gdb) bt +#0 0x0000000000000000 in ?? () +#1 0x0000007fe11adb84 in fexfn_unpack_libGL_glXCreateContextAttribsARB(fexfn_packed_args_libGL_glXCreateContextAttribsARB*) () from /usr/lib/fex-emu/HostThunks//libGL-host.so +#2 0x0000007fe25fd3d8 in ?? () +``` + +The crash is caused by `fexldr_ptr_libGL_glXCreateContextAttribsARB` (called in the unpacking function) being `nullptr`. diff --git a/results/scraper/fex/2045 b/results/scraper/fex/2045 new file mode 100644 index 000000000..7ec09a74b --- /dev/null +++ b/results/scraper/fex/2045 @@ -0,0 +1,3 @@ +Broadcom vulkan driver still breaking vulkan loader +I thought I backported the fix correctly to mesa 22.2.0 but apparently it is still broken. +Need to switch to commit in upstream to resolve. \ No newline at end of file diff --git a/results/scraper/fex/2051 b/results/scraper/fex/2051 new file mode 100644 index 000000000..1048be47a --- /dev/null +++ b/results/scraper/fex/2051 @@ -0,0 +1,4 @@ +Implement support for a timeline trace implementation +ftrace and microprofile are some pretty good tools for wiring up and is useful for seeing where CPU time is spent other than llvm-xray. + +This is fairly lightweight and could be added easily I just keep forgetting about it. \ No newline at end of file diff --git a/results/scraper/fex/2052 b/results/scraper/fex/2052 new file mode 100644 index 000000000..093071fd0 --- /dev/null +++ b/results/scraper/fex/2052 @@ -0,0 +1,4 @@ +Look at symbol leaks in libFEXCore.so +Noticed that we are exposing a bunch of global symbols even with visibility default. +The only workaround might actually be a linker script which explicitly defines what symbols we want to export? +A little crap since it adds maintenance burden but whatever. \ No newline at end of file diff --git a/results/scraper/fex/2054 b/results/scraper/fex/2054 new file mode 100644 index 000000000..8572b23ef --- /dev/null +++ b/results/scraper/fex/2054 @@ -0,0 +1,2 @@ +Thunks won't rebuild if linker script is changed +need to add a dependency tracker \ No newline at end of file diff --git a/results/scraper/fex/2071 b/results/scraper/fex/2071 new file mode 100644 index 000000000..8f3de1779 --- /dev/null +++ b/results/scraper/fex/2071 @@ -0,0 +1,8 @@ +can't run wine in proot +when i try to run 'winecfg', it cashes with 'Segmentation fault'. + +my os: android 12 with ubuntu 22.04 (proot) +fex version: 2210(fex-emu-armv8.0) + + +Thanks. \ No newline at end of file diff --git a/results/scraper/fex/2086 b/results/scraper/fex/2086 new file mode 100644 index 000000000..ed1610b33 --- /dev/null +++ b/results/scraper/fex/2086 @@ -0,0 +1,7 @@ +Trying to open Intel Quartis Prime 18.1 +Hello when I try to execute quartus using FEXBash I run into the following error: +`FEXBash-root@oriol-Parallels-ARM-Virtual-Machine:/home/oriol/Intel_Quartus/quartus/bin> ./quartus +quartus: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory +` +Thanks + diff --git a/results/scraper/fex/2095 b/results/scraper/fex/2095 new file mode 100644 index 000000000..e6fb7a18b --- /dev/null +++ b/results/scraper/fex/2095 @@ -0,0 +1,7 @@ +std::random_device can fail! +``` +terminate called after throwing an instance of 'std::runtime_error' + what(): random_device::random_device(const std::string&): device not available +``` + +We need to support a fallback path in this case, I didn't realize this was a possibility. \ No newline at end of file diff --git a/results/scraper/fex/2097 b/results/scraper/fex/2097 new file mode 100644 index 000000000..c85e9dc6a --- /dev/null +++ b/results/scraper/fex/2097 @@ -0,0 +1,2 @@ +Need FPREM/FPREM1 unit tests with mismatched sign values +This should show the differences between FPREM and FPREM1, which will show the real failure of our implementations. \ No newline at end of file diff --git a/results/scraper/fex/2104 b/results/scraper/fex/2104 new file mode 100644 index 000000000..f1b955022 --- /dev/null +++ b/results/scraper/fex/2104 @@ -0,0 +1,4 @@ +Thunks: Revisit implementation strategy for implicit library dependencies +#1880 added a libX11 dependency to libGL by creating a fake libX11 library that is discarded during installation. This carries some boilerplate code and applying it to other libraries in the future turns out somewhat laborious. + +Instead, using the `--as-needed` flag mentioned in the original PR should work rather easily after all: We can just append `--as-needed libX11.so --no-as-needed` to the `LINK_FLAGS` property of libGL. If possible, `--push-state` should be used if all linkers we support for compiling thunks implement that flag, though. diff --git a/results/scraper/fex/2121 b/results/scraper/fex/2121 new file mode 100644 index 000000000..0f7219f7a --- /dev/null +++ b/results/scraper/fex/2121 @@ -0,0 +1,3 @@ +Random stuck in termux +Hi, i am running fex2210 in termux. I use termux-chroot to solve system call problem in android. FEX 2210 runs fast and has great compatibility on my device ,but sometimes stucks here.Can anyone help me debug this problem? +Thanks \ No newline at end of file diff --git a/results/scraper/fex/2136 b/results/scraper/fex/2136 new file mode 100644 index 000000000..833fff9dd --- /dev/null +++ b/results/scraper/fex/2136 @@ -0,0 +1,5 @@ +execveat syscall incorrect with `AT_EMPTY_PATH` flag +We always pass in `/proc/self/exe` which means we end up ignoring this flag. +This causes us to potentially execute a process incorrectly since we are supposed to execute the FD rather whatever is in the arguments. +This is a fairly tricky edge case and not many people (that I'm aware of) are abusing it right now. +Will need a test-case with executing an FD that is a she-bang file, regular ELF, and with and without binfmt_misc. \ No newline at end of file diff --git a/results/scraper/fex/2138 b/results/scraper/fex/2138 new file mode 100644 index 000000000..e14b31ff1 --- /dev/null +++ b/results/scraper/fex/2138 @@ -0,0 +1,7 @@ +Mathpix Snipping tool crashes under FEX-Emu +It seems to crash early and then tries to ptrace itself for a crash log, which results in it crashing even harder. +It might be using a JIT and self-invalidation making it hard to test and debug. +Needs investigation + +Can be gotten as an AppImage here: https://mathpix.com/desktop-downloads +Current Direct: https://download.mathpix.com/linux/Mathpix_Snipping_Tool-x86_64.v03.00.0092.AppImage \ No newline at end of file diff --git a/results/scraper/fex/2140 b/results/scraper/fex/2140 new file mode 100644 index 000000000..bfd7f6f14 --- /dev/null +++ b/results/scraper/fex/2140 @@ -0,0 +1,2 @@ +Ubuntu 22.10 Support? +The new ubuntu [version](https://releases.ubuntu.com/kinetic/) was recently release and would be awsome for this to be compatible with it \ No newline at end of file diff --git a/results/scraper/fex/2142 b/results/scraper/fex/2142 new file mode 100644 index 000000000..3dff92902 --- /dev/null +++ b/results/scraper/fex/2142 @@ -0,0 +1,36 @@ +Project Zomboid Server : Fails to start +**What Game** +Project Zomboid Server (steamid: 380870 ), installed through the steamcmd + +**Describe the bug** +Trying to start the server would get a java crash + +**To Reproduce** +Steps to reproduce the behavior: +1. FEXBash +2. Go to the installed location of project zomboid server (Steam/steamapps/common/Project\ Zomboid\ Dedicated\ Server) +3. Start it `./start-server.sh -servername pzserver` + +**Expected behavior** +The server should start correctly + +**Screenshots and Video** + + + +**System information:** + - OS: Ubuntu 22.04 + - CPU/SoC: Ampere 4 cpu ARM64 + - RootFS used: Ubuntu 22.04 Official Rootfs + - FEX version: FEX-2211 + - Thunks Enabled: No + +**Additional context** + - Is this an x86 or x86-64 game: x86 + - Does this reproduce on x86-64 host with FEX: Untested + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: No + - If Yes, What is your Vulkan driver: + +Add any other context about the problem here. +This is an oracle cloud computer \ No newline at end of file diff --git a/results/scraper/fex/2173 b/results/scraper/fex/2173 new file mode 100644 index 000000000..10d037ba3 --- /dev/null +++ b/results/scraper/fex/2173 @@ -0,0 +1,16 @@ +Crypt of the Necrodancer x86-64 crashes with GL thunks +The Steam release of this build added 64-bit support at some point. +This currently crashes with GL thunks enabled inside of X11. +``` +#0 rtree_szind_slab_read (tsdn=0xfffff7ff1880, rtree_ctx=0xfffff7ff18b0, key=19736656, dependent=true, rtree=<optimized out>, r_szind=<optimized out>, r_slab=<optimized out>) + at /mnt/Work/Work/work/FEXNew/External/jemalloc/include/jemalloc/internal/rtree.h:500 +#1 ifree (ptr=0x12d2850, tcache=0xfffff7ff1a70, slow_path=false, tsd=<optimized out>) at /mnt/Work/Work/work/FEXNew/External/jemalloc/src/jemalloc.c:2570 +#2 je_free_default (ptr=0x12d2850) at /mnt/Work/Work/work/FEXNew/External/jemalloc/src/jemalloc.c:2790 +#3 0x00007fffe14d5b18 in ?? () from /lib/aarch64-linux-gnu/libX11.so.6 +#4 0x00007fffe1cd9c88 in Invoke<int, _XImage*, unsigned long> (func=0x1, args=...) at /mnt/Work/Work/work/FEXNew/ThunkLibs/HostLibs/../include/common/PackedArguments.h:159 +#5 CallbackUnpack<int (_XImage*)>::ForIndirectCall(void*) (argsv=0x7fffffff6c30) at /mnt/Work/Work/work/FEXNew/ThunkLibs/HostLibs/../include/common/Host.h:177 +#6 0x00007fffe389a7f0 in ?? () +``` + +Needs some investigation work. +https://store.steampowered.com/app/247080/Crypt_of_the_NecroDancer/ \ No newline at end of file diff --git a/results/scraper/fex/2175 b/results/scraper/fex/2175 new file mode 100644 index 000000000..4ce2f15cd --- /dev/null +++ b/results/scraper/fex/2175 @@ -0,0 +1,163 @@ +Unvanquished: Crashes with error about DEP +**What Game** + +Unvanquished, downloaded from https://unvanquished.net/download/ + +**Describe the bug** + +Trying to launch Unvanquished fails because the `nacl_loader` process crashes. + +**To Reproduce** + +1. Download the launcher for Linux +2. Unzip and execute the launcher, install Unvanquished +3. Hit the button to start the game +4. See the crash + +**Expected behavior** + +The game should not crash. + +**Screenshots and Video** + +<details> + +<summary>Logs:</summary> + +``` +ixn@jammy:/tmp$ ~/.local/share/unvanquished/base/daemon +Unvanquished 0.53.2 Linux x86_64 Sep 4 2022 +cmdline: +[FS] Lib path: /home/ixn/.local/share/unvanquished/base +[FS] Home path: /home/ixn/.local/share/unvanquished +[FS] Pak search path: /home/ixn/.local/share/unvanquished/base/pkg +[FS] Pak search path: /home/ixn/.local/share/unvanquished/pkg +Starting crash logging server +[FS] Loading pak '/home/ixn/.local/share/unvanquished/base/pkg/unvanquished_0.53.2.dpk'... +[FS] Loading pak '/home/ixn/.local/share/unvanquished/base/pkg/unvanquished_0.52.0.dpk'... +[FS] Loading pak '/home/ixn/.local/share/unvanquished/base/pkg/tex-common_2.2.dpk'... +[FS] Loading pak '/home/ixn/.local/share/unvanquished/base/pkg/res-players_0.53.0.dpk'... +[FS] Loading pak '/home/ixn/.local/share/unvanquished/base/pkg/res-players_0.52.dpk'... +[FS] Loading pak '/home/ixn/.local/share/unvanquished/base/pkg/res-legacy_0.52.dpk'... +[FS] Loading pak '/home/ixn/.local/share/unvanquished/base/pkg/res-weapons_0.53.0.dpk'... +[FS] Loading pak '/home/ixn/.local/share/unvanquished/base/pkg/res-weapons_0.52.1.dpk'... +[FS] Loading pak '/home/ixn/.local/share/unvanquished/base/pkg/res-weapons_0.52.dpk'... +[FS] Loading pak '/home/ixn/.local/share/unvanquished/base/pkg/res-buildables_0.53.0.dpk'... +[FS] Loading pak '/home/ixn/.local/share/unvanquished/base/pkg/res-buildables_0.52.dpk'... +[FS] Loading pak '/home/ixn/.local/share/unvanquished/base/pkg/res-voices_0.52.dpk'... +[FS] Loading pak '/home/ixn/.local/share/unvanquished/base/pkg/res-soundtrack_0.52.dpk'... +execing 'default.cfg' +execing 'presets/input/wasd.cfg' +Warn: Couldn't read conhistory: No such file or directory +----- Client Initialization ----- +Loading RSA keys from pubkey +Daemon RSA public-key found. +----- Client Initialization Complete ----- +IP: 127.0.0.1 +IP: 192.168.10.50 +IP: 192.168.10.100 +IP: 10.0.3.1 +IP6: ::1 +IP6: fe80::2ebd:a9a2:fa21:99c%enP4p65s0 +Opening IP6 socket: [::]:* +Opening IP socket: 0.0.0.0:* +--- Common Initialization Complete --- +Calling GetRefAPI… +SDL_Init( SDL_INIT_VIDEO )... +Using SDL version 2.0.12 +SDL using driver "x11" +Initializing OpenGL display +Using GLEW version 2.2.0 +Display aspect: 1.250 +Display resolution: 1280x1024 +...setting mode -2: 1280×1024 +Using preferred context - 24-bit OpenGL 2.1 compatibility +OpenGL Renderer: Mali-G610 (Panfrost) +Warn: Provided OpenGL 3.0 is not the same as requested 2.1 version +Using GL3 Renderer in OpenGL 2.x mode... +Available modes: '1280x1024 320x240 800x600 1024x768 1152x864 1280x960 720x480 640x400 1280x800 864x486 1024x576 1280x720 720x400 640x350 ' +Detected graphics driver class 'integrated' +Detected graphics hardware class 'generic' +Initializing OpenGL extensions +...ignoring GL_ARB_debug_output +...found shading language version 130 +...using GL_ARB_half_float_pixel +...using GL_ARB_texture_float +...using GL_EXT_gpu_shader4 +...using GL_EXT_texture_integer +...using GL_ARB_texture_rg +...using GL_ARB_texture_gather +...using GL_EXT_texture_compression_s3tc +...using GL_ARB_texture_compression_rgtc +...using GL_EXT_texture_filter_anisotropic +...using GL_ARB_half_float_vertex +...using GL_ARB_framebuffer_object +...using GL_ARB_get_program_binary +...using GL_ARB_buffer_storage +...using GL_ARB_uniform_buffer_object +...using GL_ARB_map_buffer_range +...using GL_ARB_sync +GL_VENDOR: Panfrost +GL_RENDERER: Mali-G610 (Panfrost) +GL_VERSION: 3.0 Mesa 23.0.0-devel (git-fd340d5154) +GL_MAX_TEXTURE_SIZE: 8192 +GL_SHADING_LANGUAGE_VERSION: 1.30 +GL_MAX_VERTEX_UNIFORM_COMPONENTS 16352 +GL_MAX_VERTEX_ATTRIBS 16 +Occlusion query bits: 64 +GL_MAX_DRAW_BUFFERS: 8 +GL_TEXTURE_MAX_ANISOTROPY_EXT: 16.000000 +GL_MAX_RENDERBUFFER_SIZE: 8192 +GL_MAX_COLOR_ATTACHMENTS: 8 +PIXELFORMAT: color(24-bits) +MODE: -2, 1280 x 1024 fullscreen hz: N/A +Using OpenGL version 3.0, requested: 2.1 +Using OpenGL 2.x context. +Using OpenGL extensions: GL_ARB_half_float_pixel GL_ARB_texture_float GL_EXT_gpu_shader4 GL_EXT_texture_integer GL_ARB_texture_rg GL_ARB_texture_gather GL_EXT_texture_compression_s3tc GL_ARB_texture_compression_rgtc GL_EXT_texture_filter_anisotropic GL_ARB_half_float_vertex GL_ARB_framebuffer_object GL_ARB_get_program_binary GL_ARB_buffer_storage GL_ARB_uniform_buffer_object GL_ARB_map_buffer_range GL_ARB_sync +Using S3TC (DXTC) texture compression. +Using GPU vertex skinning with max 256 bones in a single pass, models are hardware accelerated. +][ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1) +[ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1) +Extracting VM module cgame-x86_64.nexe from /home/ixn/.local/share/unvanquished/base/pkg/unvanquished_0.53.2.dpk... + +Loading VM module cgame-x86_64.nexe... +Using loader args: /home/ixn/.local/share/unvanquished/base/nacl_helper_bootstrap /home/ixn/.local/share/unvanquished/base/nacl_loader --r_debug=0xXXXXXXXXXXXXXXXX --reserved_at_zero=0xXXXXXXXXXXXXXXXX -v -B /home/ixn/.local/share/unvanquished/base/irt_core-x86_64.nexe -e -i 100:45 -- /home/ixn/.local/share/unvanquished/cgame-x86_64.nexe 100 +Warn: Error during initialization: IPC: Socket closed by remote end +Error during cgame shutdown: IPC: Failed to send message: Broken pipe +Warn: VM exited with non-zero exit code 2 + +ixn@jammy:/tmp$ /home/ixn/.local/share/unvanquished/base/nacl_helper_bootstrap /home/ixn/.local/share/unvanquished/base/nacl_loader --r_debug=0xXXXXXXXXXXXXXXXX --reserved_at_zero=0xXXXXXXXXXXXXXXXX -v -B /home/ixn/.local/share/unvanquished/base/irt_core-x86_64.nexe -e -i 100:45 -- /home/ixn/.local/share/unvanquished/cgame-x86_64.nexe 100 +sel_ldr argument list: +/home/ixn/.local/share/unvanquished/base/nacl_loader --r_debug=0x0000000000213000 --reserved_at_zero=0x0000000000000000 -v -B /home/ixn/.local/share/unvanquished/base/irt_core-x86_64.nexe -e -i 100:45 -- /home/ixn/.local/share/unvanquished/cgame-x86_64.nexe 100 +[48090,2293663616:21:20:52.368948] Error while loading "/home/ixn/.local/share/unvanquished/cgame-x86_64.nexe": Data Execution Prevention is required but is not supported +[48090,2293663616:21:20:52.397326] NaClPerfCounterInterval(SelMain __start__:SnapshotBlob): 49539 microsecs +[48090,2293663616:21:20:52.400980] NACL: Application output follows +[48090,2293663616:21:20:52.401246] NaClAppStartModule: module not loaded +Dumping vmmap. +In PrintVmmap +Done. +``` + +The important line appears to be this: + +`[48090,2293663616:21:20:52.368948] Error while loading "/home/ixn/.local/share/unvanquished/cgame-x86_64.nexe": Data Execution Prevention is required but is not supported` + +</details> + +**System information:** + - OS: Ubuntu 22.04 in bubblewrap container + - CPU/SoC: Rockchip RK3588 + - Video driver version: OpenGL 3.0 Mesa 23.0.0-devel (git-fd340d5154), with ARM assembly patched out + - RootFS used: Ubuntu 22.04 Official Rootfs + - FEX version: FEX-2211-2-g5336f01 + - Thunks Enabled: No + +**Additional context** + - Is this an x86 or x86-64 game: x86-64 + - Does this reproduce on x86-64 host with FEX: Untested + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: No + +The check for DEP appears to be here: + +https://source.chromium.org/chromium/chromium/src/+/main:native_client/src/trusted/platform_qualify/posix/nacl_dep_qualify.c;l=147;drc=c3304aefc16d3c021c637ea6edfd9a8ab750a2db diff --git a/results/scraper/fex/2189 b/results/scraper/fex/2189 new file mode 100644 index 000000000..9064f0c9f --- /dev/null +++ b/results/scraper/fex/2189 @@ -0,0 +1,54 @@ +How can I fix crashed In XSetErrorHandler? +source code: +https://github.com/opengl-tutorials/ogl + +how to reproduce: +1. open -DBUILD_THUNKS, build FEXLoader +2. run tutorial01_first_window +3. FEXLoader crashed + +Guest Code error position: ogl/external/glfw-3.1.2/src/x11_init.c:680, XSetErrorHandler +``` +void _glfwReleaseXErrorHandler(void) +{ + // Synchronize to make sure all commands are processed + XSync(_glfw.x11.display, False); + XSetErrorHandler(NULL); +} +``` + +FEXLoader Crash position: Thunks.cpp:436, FinalizeHostTrampolineForGuestFunction +``` + FEX_DEFAULT_VISIBILITY + void FinalizeHostTrampolineForGuestFunction(HostToGuestTrampolinePtr* TrampolineAddress, void* HostPacker) { + auto& Trampoline = GetInstanceInfo(TrampolineAddress); + + LOGMAN_THROW_A_FMT(Trampoline.CallCallback == (uintptr_t)&ThunkHandler_impl::CallCallback, + "Invalid trampoline at {} passed to {}", fmt::ptr(TrampolineAddress), __FUNCTION__); + + if (!Trampoline.HostPacker) { + LogMan::Msg::DFmt("Thunks: Finalizing trampoline at {} with host packer {}", fmt::ptr(TrampolineAddress), fmt::ptr(HostPacker)); + Trampoline.HostPacker = HostPacker; + } + } +``` + +It seems when I pass a callback ptr is NULL to XSetErrorHandler, TrampolineAddress is NULL too, so GetInstanceInfo return error info. and LOGMAN_THROW_A_FMT thow a exception. + +so is it right to fix this problem like this, immediate return when TrampolineAddress is NULL: +``` + FEX_DEFAULT_VISIBILITY + void FinalizeHostTrampolineForGuestFunction(HostToGuestTrampolinePtr* TrampolineAddress, void* HostPacker) { + if (TrampolineAddress == nullptr) return; + + auto& Trampoline = GetInstanceInfo(TrampolineAddress); + + LOGMAN_THROW_A_FMT(Trampoline.CallCallback == (uintptr_t)&ThunkHandler_impl::CallCallback, + "Invalid trampoline at {} passed to {}", fmt::ptr(TrampolineAddress), __FUNCTION__); + + if (!Trampoline.HostPacker) { + LogMan::Msg::DFmt("Thunks: Finalizing trampoline at {} with host packer {}", fmt::ptr(TrampolineAddress), fmt::ptr(HostPacker)); + Trampoline.HostPacker = HostPacker; + } + } +``` diff --git a/results/scraper/fex/2192 b/results/scraper/fex/2192 new file mode 100644 index 000000000..7324b45b4 --- /dev/null +++ b/results/scraper/fex/2192 @@ -0,0 +1,104 @@ +[wine-i386]: [opengl can't detect hardware vendor] +**wine-i386 and winecheck* +Wine(https://www.winehq.org/) +winecheck + + +**Describe the bug** +I try to run x86 program in ubuntu-aarch64, so i use FEXLoader to load wine, then wine load x86 program wincheck.exe. But it seems cant find vendor +``` +progwrapper$ FEXLoader -R Ubuntu_i386 ./wine-progwrapper/bin/wine ./winecheck.exe +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 111 Connection refused +RootFS Position: /home/bogus/.fex-emu/RootFS/Ubuntu_i386 : ./wine-progwrapper/bin/wine +RootFS Position: /home/bogus/.fex-emu/RootFS/Ubuntu_i386 : /usr/local/share/progwrapper/wine-progwrapper/bin/wine-preloader +RootFS Position: /home/bogus/.fex-emu/RootFS/Ubuntu_i386 : /usr/local/share/progwrapper/wine-progwrapper/bin/wineserver +fixme:winediag:start_process Wine Staging 1.9.7 is a testing version containing experimental patches. +fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org. +err:menubuilder:init_xdg error looking up the desktop directory +Checking OpenGL ... +radeon: Failed to get PCI ID, error number -1 +libGL error: failed to create dri screen +libGL error: failed to load driver: radeonsi +OpenGL Vendor: VMware, Inc. +OpenGL Renderer: llvmpipe (LLVM 6.0, 128 bits) +OpenGL Direct Rendering: True +ERROR: found bad OpenGL Vendor: VMware, Inc. +ERROR: found bad OpenGL Renderer: llvmpipe +OpenGL: FAILURE +``` +I read the source code, it seems failure in below part code, like this(https://github.com/wine-mirror/wine/blob/master/dlls/opengl32/tests/opengl.c#L1190), but is not the same: +``` + hWnd = CreateWindowExA(0, clsName, "OpenGL Test", WS_TILEDWINDOW, 0, 0, 100, 100, 0, 0, 0, 0); + if (!hWnd) + return false; + + hDC = GetDC(hWnd); + if (!hDC) + goto error; + + pixelformat = ChoosePixelFormat(hDC, &pfd); + if (!pixelformat) + goto error; + + if (!SetPixelFormat(hDC, pixelformat, &pfd)) + goto error; + + context = wglCreateContext(hDC); + if (!context) + goto error; + + if (!wglMakeCurrent(hDC, context)) + goto error; + + vendor = (const char *)glGetString(GL_VENDOR); + renderer = (const char *)glGetString(GL_RENDERER); + extensions = (const char *)glGetString(GL_EXTENSIONS); + + if (extensions && strstr(extensions, "WINE_EXT_direct_rendering")) + directRendering = true; + + printf("OpenGL Vendor: %s\n", vendor); + printf("OpenGL Renderer: %s\n", renderer); + printf("OpenGL Direct Rendering: %s\n", + directRendering ? "True" : "False (or old/wrong wine version)"); +``` +glGetString(GL_VENDOR) cant get real vendor info, it's just return software implement. + +real vendor info : + + +Because I cant run winecheck, so I use some opengl test program do test, all is ok + +1. FEXLoader ~/Downloads/ogl/glxinfo +2. WINEPREFIX="/home/bogus/.wine64/" ./wine ~/.wine64/drive_c/users/bogus/Temp/wct/opengl32_test.exe +3. FEXLoader -k ~/.fex-emu/ThunkConfigs/thunks.json -t /usr/lib/fex-emu/HostThunks/ -j /usr/share/fex-emu/GuestThunks -R ~/.fex-emu/RootFS/Ubuntu_22_04 -- ~/Downloads/ogl/glxinfo + +And I think it is maybe FEX not implement some opengl32 compatibility interface, But how can I to verify my guess and to fix it? + +**To Reproduce** +FEXLoader -R Ubuntu_i386 ./wine-progwrapper/bin/wine ./winecheck.exe + +**Expected behavior** +should like this: + + +**Screenshots and Video** + + +**System information:** + - OS: Ubuntu 22.04.1 LTS + - CPU/SoC: AMD + - Video driver version: Device: AMD OLAND (LLVM 13.0.1, DRM 2.50, 5.15.0-54-generic) (0x6611) + - RootFS used: Ubuntu 16.04 (i386) + - FEX version: commit c37fcf136ababf13b491ae8f1a878cc70f8d1c33 (FEXGetConfig build by myself, it seems is the latest version ) + - Thunks Enabled: No (I don't know how to enable libgl32 thunk) + +**Additional context** + - Is this an x86 or x86-64 game: No + - Does this reproduce on x86-64 host with FEX: NoTest + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: yes + - Is this a Vulkan game: No + - + +**And I think it is maybe FEX not implement some opengl32 compatibility interface, But how can I to verify my guess and to fix it?** + diff --git a/results/scraper/fex/2199 b/results/scraper/fex/2199 new file mode 100644 index 000000000..d598ba7ca --- /dev/null +++ b/results/scraper/fex/2199 @@ -0,0 +1,2 @@ +Add BIC IR op for ANDN emulation +Currently we are just doing a not+and dance. We can use BIC for these directly to save an instruction. \ No newline at end of file diff --git a/results/scraper/fex/2203 b/results/scraper/fex/2203 new file mode 100644 index 000000000..e65a7ff38 --- /dev/null +++ b/results/scraper/fex/2203 @@ -0,0 +1,41 @@ +Crash on XCloseDisplay +**desc** +crash on tutor07(https://github.com/opengl-tutorials/ogl/blob/316cccc5f76f47f09c16089d98be284b689e057d/tutorial07_model_loading/tutorial07.cpp#L183) + +This crash partially similar to #2173 + +Below is my crash stack: +``` +* thread #1, name = 'FEXLoader', stop reason = signal SIGSEGV + frame #0: 0x0000aaaab515d5cc FEXLoader`je_free_default [inlined] atomic_load_p(a=0x00000000001dd408, mo=atomic_memory_order_relaxed) at atomic.h:62:1 + frame #1: 0x0000aaaab515d518 FEXLoader`je_free_default [inlined] rtree_leaf_elm_bits_read(tsdn=0x0000ffffa319a830, rtree=0x0000aaaab566b440, elm=0x00000000001dd408, dependent=true) at rtree.h:175:20 + frame #2: 0x0000aaaab515d500 FEXLoader`je_free_default [inlined] rtree_szind_slab_read(tsdn=0x0000ffffa319a830, rtree=0x0000aaaab566b440, rtree_ctx=0x0000ffffa319a860, key=94100513102016, dependent=true, r_szind=0x0000ffffe1720718, r_slab=0x0000ffffe172071c) at rtree.h:500:19 + frame #3: 0x0000aaaab515cfac FEXLoader`je_free_default [inlined] ifree(tsd=0x0000ffffa319a830, ptr=0x000055957ba818c0, tcache=0x0000ffffa319aa20, slow_path=false) at jemalloc.c:2570:2 + frame #4: 0x0000aaaab515cebc FEXLoader`je_free_default(ptr=0x000055957ba818c0) at jemalloc.c:2790:4 + frame #5: 0x0000aaaab5167808 FEXLoader`je_free(ptr=0x000055957ba818c0) at jemalloc.c:2867:3 + frame #6: 0x00007fffe15e018c libX11.so.6`XFree + 12 + frame #7: 0x00007fffe15e01c8 libX11.so.6`_XFreeEventCookies + 40 + frame #8: 0x00007fffe15cdee4 libX11.so.6`_XFreeDisplayStructure + 96 + frame #9: 0x00007fffe15c0084 libX11.so.6`XCloseDisplay + 180 + * frame #10: 0x00007fffe1731008 libX11-host.so`fexfn_unpack_libX11_XCloseDisplay(fexfn_packed_args_libX11_XCloseDisplay*) + 24 + frame #11: 0x00007fffe3634f54 +``` + +** reproduce command ** +FEXLoader tutorial07_model_loading + +**System information:** + - OS: Ubuntu 22.04.1 LTS + - CPU/SoC: AMD + - Video driver version: Device: AMD OLAND (LLVM 13.0.1, DRM 2.50, 5.15.0-54-generic) (0x6611) + - RootFS used: Ubuntu 22.04(x64) + - FEX version: FEX-Emu (FEX-2212-9-g9eaa45f) + - Thunks Enabled: Yes + +** question ** +how can we analysis this type problem ? + +1. I want to (https://github.com/glfw/glfw) build a libglfw.so by self, to print more trace info, narrow down this problem. +2. From the crash trace stack, it seems relation to thunk guest-host memory , FEX have any methods to detect this problem? eg. add memory check in runtime , like as _FEXgdb_ attach to FEXLoader, then stop it, invoke some _mem_check_ command. or eg. like valgrind? + +Do you have any suggestions for me? \ No newline at end of file diff --git a/results/scraper/fex/2204 b/results/scraper/fex/2204 new file mode 100644 index 000000000..9b86d0a90 --- /dev/null +++ b/results/scraper/fex/2204 @@ -0,0 +1,9 @@ +Empty LockMutexFuncton ? +libX11 library two function not implemented + +LockMutexFunction +UnlockMutexFunction + +https://github.com/FEX-Emu/FEX/blob/9eaa45f92223ad4eecbe07df0529d8e4d15a7215/ThunkLibs/libX11/libX11_Guest.cpp#L153-L159 + +when I run gl test program, it print much error info, is it ok? \ No newline at end of file diff --git a/results/scraper/fex/2213 b/results/scraper/fex/2213 new file mode 100644 index 000000000..8015c8bf7 --- /dev/null +++ b/results/scraper/fex/2213 @@ -0,0 +1,2 @@ +Handle difference between UCOMIS and COMIS +Currently we don't do anything different between the two types of instructions. \ No newline at end of file diff --git a/results/scraper/fex/2220 b/results/scraper/fex/2220 new file mode 100644 index 000000000..e0c47bd83 --- /dev/null +++ b/results/scraper/fex/2220 @@ -0,0 +1,5 @@ +Build fails - CMake Error +On Asahi Linux, I tried installing both from the AUR (fex-emu and fex-emu-git) as well as manually following the wiki directions. In all cases, I get the following CMake error: + +ModuleNotFoundError: No module named 'pkg_resources' +CMake Error at CMakeLists.txt:298 (strong): string sub-command STRIP requires two arguments. \ No newline at end of file diff --git a/results/scraper/fex/2256 b/results/scraper/fex/2256 new file mode 100644 index 000000000..11c173a4c --- /dev/null +++ b/results/scraper/fex/2256 @@ -0,0 +1,87 @@ +Crash on winecheck.exe +reproduce command: + +``` +FEXLoader ./wine-1.6/bin/wine ~/Downloads/ogl/winecheck.exe + +fixme:winediag:start_process Wine Staging 1.9.7 is a testing version containing experimental patches. +fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org. +Checking OpenGL ... +OpenGL Vendor: X.Org +OpenGL Renderer: AMD OLAND (DRM 2.50.0 / 5.15.0, LLVM 6.0.0) +OpenGL Direct Rendering: True +OpenGL: PASSED + +Checking fonts ... +Found Arial in wine\fonts\Arial.ttf +Found Arial in wine\fonts\Arial_Bold.ttf +Found Arial in wine\fonts\Arial_Bold_Italic.ttf +Found Arial in wine\fonts\Arial_Italic.ttf +Found Verdana in wine\fonts\Verdana.ttf +Found Verdana in wine\fonts\Verdana_Bold.ttf +Found Verdana in wine\fonts\Verdana_Bold_Italic.ttf +Found Verdana in wine\fonts\Verdana_Italic.ttf +Fonts: PASSED + +Checking ACLs / XATTR ... +ACLs: PASSED +Segmentation fault (core dumped) +``` + +winecheck.exe source code: + +https://github.com/keithbowes/pipelight/blob/40dbef17afd4d559f7e923e4970c2468fd30c83b/src/windows/winecheck/check.c + +Desc: +it seems if winecheck invoke checkOpenGL function ,then wine will crash on random point near main function exit. and crash chance is not 100%, below 50%. + +https://github.com/keithbowes/pipelight/blob/40dbef17afd4d559f7e923e4970c2468fd30c83b/src/windows/winecheck/check.c#L509 + +``` +crash stack： +Process 12348 stopped +* thread #3, name = 'radeon_cs:0', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) + frame #0: 0x0000000000000000 +error: memory read failed for 0x0 + thread #6, name = 'si_shader:2', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) + frame #0: 0x0000000000000000 +error: memory read failed for 0x0 + thread #8, name = 'si_shader_low:1', stop reason = signal SIGSEGV: address access protected (fault address: 0x2f5cfd800) + frame #0: 0x0000ffffa5832060 libc.so.6`__GI___pthread_mutex_unlock_usercnt at pthread_mutex_unlock.c:40:30 +(lldb) bt +* thread #3, name = 'radeon_cs:0', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) + * frame #0: 0x0000000000000000 +(lldb) bt +* thread #3, name = 'radeon_cs:0', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) + * frame #0: 0x0000000000000000 +(lldb) thread list +Process 12348 stopped + thread #1: tid = 12348, 0x0000ffffa5887910 libc.so.6`__libc_open64(file="/home/bogus/.fex-emu/Telemetry/winecheck.exe.telem.1", oflag=<unavailable>) at open64.c:41:10, name = 'winecheck.exe' +* thread #3: tid = 12473, 0x0000000000000000, name = 'radeon_cs:0', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) + thread #6: tid = 12476, 0x0000000000000000, name = 'si_shader:2', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) + thread #8: tid = 12478, 0x0000ffffa5832060 libc.so.6`__GI___pthread_mutex_unlock_usercnt at pthread_mutex_unlock.c:40:30, name = 'si_shader_low:1', stop reason = signal SIGSEGV: address access protected (fault address: 0x2f5cfd800) +(lldb) t 6 +* thread #6, name = 'si_shader:2', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) + frame #0: 0x0000000000000000 +error: memory read failed for 0x0 +(lldb) bt +* thread #6, name = 'si_shader:2', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) + * frame #0: 0x0000000000000000 +(lldb) +``` + +I add debug info in RADEON_Handler, but near the main exit point, it not invoke RADEON_Handler. + +One thread show it's name is radeon_cs, it's a ioctl cmd +``` +struct drm_radeon_cs { + __u32 num_chunks; + __u32 cs_id; + /* this points to __u64 * which point to cs chunks */ + __u64 chunks; + /* updates to the limits after this CS ioctl */ + __u64 gart_limit; + __u64 vram_limit; +}; +``` +I think the crash relation with openGL. But I don't know how to analysis this problem. \ No newline at end of file diff --git a/results/scraper/fex/227 b/results/scraper/fex/227 new file mode 100644 index 000000000..57aa0bc19 --- /dev/null +++ b/results/scraper/fex/227 @@ -0,0 +1,4 @@ +Iris/i965 has rendering bug with glxgears +Not sure if this ever worked. I don't test frequently on Intel hosts. +Both i965 and Iris have rendering issues. Probably breaking something in their shader compiler? + diff --git a/results/scraper/fex/2270 b/results/scraper/fex/2270 new file mode 100644 index 000000000..6d5b84cce --- /dev/null +++ b/results/scraper/fex/2270 @@ -0,0 +1,58 @@ +'bits/c++config.h' file not found +## error info + +``` +[1/3] Generating gen/thunkgen_guest_libVDSO.inl +FAILED: gen/thunkgen_guest_libVDSO.inl /home/bogus/source/FEX/build-Release-Thunk/Guest_32/gen/thunkgen_guest_libVDSO.inl +cd /home/bogus/source/FEX/build-Release-Thunk/Guest_32 && /home/bogus/source/FEX/build-Release-Thunk/Bin/thunkgen /home/bogus/source/FEX/ThunkLibs/GuestLibs/../libVDSO/libVDSO_interface.cpp libVDSO -guest /home/bogus/source/FEX/build-Release-Thunk/Guest_32/gen/thunkgen_guest_libVDSO.inl -- -std=c++17 -m32 --target=i686-linux-unknown -isystem /usr/i686-linux-gnu/include/ -DGUEST_THUNK_LIBRARY -isystem/home/bogus/source/FEX/ThunkLibs/GuestLibs/../include +In file included from /home/bogus/source/FEX/ThunkLibs/GuestLibs/../libVDSO/libVDSO_interface.cpp:7: +In file included from /home/bogus/source/FEX/ThunkLibs/GuestLibs/../libVDSO/Types.h:2: +/usr/lib/gcc-cross/i686-linux-gnu/11/../../../../include/c++/11/cstdint:38:10: fatal error: 'bits/c++config.h' file not found +#include <bits/c++config.h> + ^~~~~~~~~~~~~~~~~~ +1 error generated. +Error while processing /home/bogus/source/FEX/ThunkLibs/GuestLibs/../libVDSO/libVDSO_interface.cpp. +ninja: build stopped: subcommand failed. +``` + +I search c++config.h in /usr +``` +bogus@bogus:/usr$ find * | grep "c++config.h" +aarch64-linux-gnu/include/c++/10/aarch64-linux-gnu/bits/c++config.h +i686-linux-gnu/include/c++/10/i686-linux-gnu/bits/c++config.h +i686-linux-gnu/include/c++/10/i686-linux-gnu/64/bits/c++config.h +i686-linux-gnu/include/c++/10/i686-linux-gnu/x32/bits/c++config.h +i686-linux-gnu/include/c++/11/i686-linux-gnu/bits/c++config.h +i686-linux-gnu/include/c++/11/i686-linux-gnu/64/bits/c++config.h +i686-linux-gnu/include/c++/11/i686-linux-gnu/x32/bits/c++config.h +include/aarch64-linux-gnu/c++/10/bits/c++config.h +include/aarch64-linux-gnu/c++/9/bits/c++config.h +include/aarch64-linux-gnu/c++/11/bits/c++config.h +x86_64-linux-gnu/include/c++/10/x86_64-linux-gnu/bits/c++config.h +x86_64-linux-gnu/include/c++/10/x86_64-linux-gnu/x32/bits/c++config.h +x86_64-linux-gnu/include/c++/10/x86_64-linux-gnu/32/bits/c++config.h +x86_64-linux-gnu/include/c++/11/x86_64-linux-gnu/bits/c++config.h +x86_64-linux-gnu/include/c++/11/x86_64-linux-gnu/x32/bits/c++config.h +x86_64-linux-gnu/include/c++/11/x86_64-linux-gnu/32/bits/c++config.h +``` + +But the CMake search in director: /usr/include/c++/11, I installed so much multilib + +``` +bogus@bogus:/usr$ apt list --installed | grep multi + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +g++-11-multilib-i686-linux-gnu/jammy-updates,jammy-security,now 11.3.0-1ubuntu1~22.04cross1 arm64 [installed,automatic] +g++-11-multilib-x86-64-linux-gnu/jammy,now 11.2.0-17ubuntu1cross1 arm64 [installed,upgradable to: 11.3.0-1ubuntu1~22.04cross1] +g++-multilib-i686-linux-gnu/jammy,now 4:11.2.0-1ubuntu1 arm64 [installed] +g++-multilib-x86-64-linux-gnu/jammy,now 4:11.2.0-1ubuntu1 arm64 [installed] +gcc-11-multilib-i686-linux-gnu/jammy-updates,jammy-security,now 11.3.0-1ubuntu1~22.04cross1 arm64 [installed,automatic] +gcc-11-multilib-x86-64-linux-gnu/jammy,now 11.2.0-17ubuntu1cross1 arm64 [installed,upgradable to: 11.3.0-1ubuntu1~22.04cross1] +gcc-multilib-i686-linux-gnu/jammy,now 4:11.2.0-1ubuntu1 arm64 [installed,automatic] +gcc-multilib-x86-64-linux-gnu/jammy,now 4:11.2.0-1ubuntu1 arm64 [installed,automatic] +krb5-multidev/jammy,now 1.19.2-2 arm64 [installed,automatic] +multipath-tools/jammy-updates,jammy-security,now 0.8.8-1ubuntu1.22.04.1 arm64 [installed,automatic] +``` + +how can I fix this problem? \ No newline at end of file diff --git a/results/scraper/fex/2271 b/results/scraper/fex/2271 new file mode 100644 index 000000000..82c97043f --- /dev/null +++ b/results/scraper/fex/2271 @@ -0,0 +1,7 @@ +gpuviz load *.dat failed +## reproduce command +https://github.com/mikesart/gpuvis/wiki/trace-cmd + +## desc + + diff --git a/results/scraper/fex/2289 b/results/scraper/fex/2289 new file mode 100644 index 000000000..8742c5e44 --- /dev/null +++ b/results/scraper/fex/2289 @@ -0,0 +1,14 @@ +how to dump the generated arm64 aot file ? +Hi + +According the article [Reverse-engineering Rosetta 2 part1: Analyzing AOT files and the Rosetta 2 runtime](https://ffri.github.io/ProjectChampollion/part1/) , the M1 rosetta system will generate a arm64 aot file when run x64 file. + +this is a simple x86_64 hello example in my m1 : +<img width="779" alt="image" src="https://user-images.githubusercontent.com/618485/209296032-08b6ab24-2893-47a9-8fcb-e9b600f2db2e.png"> + +this is the generated arm64 file: +<img width="825" alt="image" src="https://user-images.githubusercontent.com/618485/209296135-f629da4e-932f-4c80-91aa-248c62468f80.png"> + + + +so, In FEX, Is it will generate some Intermediate format file , like IR-aot, arm64 aot file , to simpify debugging , analyzing, optimizing ? how to enable or dump it ? \ No newline at end of file diff --git a/results/scraper/fex/2291 b/results/scraper/fex/2291 new file mode 100644 index 000000000..585226d44 --- /dev/null +++ b/results/scraper/fex/2291 @@ -0,0 +1,46 @@ +How to use AOTIR in right way ? +Hi + +I write a simple hello.c to test AOTIR. + +``` +#include <stdio.h> +#include <stdlib.h> + + +int main() +{ + puts("hello, world!"); + puts("hello, hello, hello "); + return 0; +} +``` + +When I want to use AOTIR feature, + +1. change ~/.fex-emu/Config.json:AOTIRCapture to 1. +2. run prog: +``` +~/source/FEX/build-Release-Thunk/Bin/FEXLoader -- ./hello +``` +to generate aotir file in ~/.fex-emu/aotir/ directory, +3. change AOTIRCatpure back to 0, AOTIRLoad to 1, +4. run above command again, now it will use aotir feature + +**First Question:** +Have a simple way to use this feature ? I dont want to change config file again and again. + +If i set both AOTIRCapture and AOTIRLoad to 1, then FEX crashed in a null pointer deference. + +**Second Question:** +``` +bogus@bogus:~/source/test/hello$ ~/source/FEX/build-Release-Thunk/Bin/FEXLoader -- ./hello +try to open file: /home/bogus/.fex-emu/aotir/ld.so.cache-16224829478350186670-sTlP.aotir +try to open file: /home/bogus/.fex-emu/aotir/libc.so.6-15624069436683325548-sTlP.aotir +hello, world! +hello, hello, hello +``` +I found the FEX not use hello-*.aotir, why ? + +**Third Question:** +what is aotir format? I drag the file into Ghidra , it seems not be recognized. \ No newline at end of file diff --git a/results/scraper/fex/2336 b/results/scraper/fex/2336 new file mode 100644 index 000000000..7ee7721da --- /dev/null +++ b/results/scraper/fex/2336 @@ -0,0 +1,13 @@ +Chromium sandbox tracking bug. +Chromium applications executed under FEX can't correctly use their sandbox in our environment currently. +Usually this can be resolved by passing the application `--no-sandbox` which will disable the sandbox. +Not all applications support this, and some will refuse to run if passed that option. + +At some point FEX needs to support running the sandbox environment but this will be a tracking bug when we find applications that hit this issue. + +Known applications that use chromium's sandbox +- ~~steamwebhelper~~ +- Mathpix snippping tool +- Chrome/Chromium +- anki flashcards +- Some game launchers that I need to find again \ No newline at end of file diff --git a/results/scraper/fex/2352 b/results/scraper/fex/2352 new file mode 100644 index 000000000..6a8bf066c --- /dev/null +++ b/results/scraper/fex/2352 @@ -0,0 +1,107 @@ +Steam: Core Dumping +**What Game** +Steam itself + +**Describe the bug** +Core Dump + +**To Reproduce** +1. install steam from official deb package: +``` + +# create necessary directories +mkdir -p ~/steam +mkdir -p ~/steam/tmp +cd ~/steam/tmp + +# download latest deb and unpack +wget https://cdn.cloudflare.steamstatic.com/client/installer/steam.deb +ar x steam.deb +tar xf data.tar.xz + +# remove deb archives, not needed anymore +rm ./*.tar.xz ./steam.deb + +# move deb contents to steam folder +mv ./usr/* ../ +cd ../ && rm -rf ./tmp/ + +# create run script +echo '#!/bin/bash +export STEAMOS=1 +export STEAM_RUNTIME=1 +export DBUS_FATAL_WARNINGS=0 +exec FEXInterpreter ~/steam/bin/steam "$@"' > steam + +# make script executable and move +chmod +x steam +mkdir -p ~/.local/bin +ln -s "$PWD/steam" ~/.local/bin/ +``` +2. `$ steam` + +**Expected behavior** +Seeing UI + +**Screenshots and Video** +``` +$ steam +steam.sh[16930]: Running Steam on ubuntu 22.04 64-bit +steam.sh[16930]: STEAM_RUNTIME is enabled by the user +setup.sh[16995]: Steam runtime environment up-to-date! +steam.sh[16930]: Steam client's requirements are satisfied +[2023-01-26 02:24:06] Startup - updater built Dec 15 2022 21:26:49 +[2023-01-26 02:24:06] Startup - Steam Client launched with: '/home/user/.local/share/Steam/ubuntu12_32/steam' +Installing breakpad exception handler for appid(steam)/version(1671236931) +Looks like steam didn't shutdown cleanly, scheduling immediate update check +[2023-01-26 02:24:07] Loading cached metrics from disk (/home/user/.local/share/Steam/package/steam_client_metrics.bin) +[2023-01-26 02:24:07] Failed to load cached hosts file (File 'update_hosts_cached.vdf' not found), using defaults +[2023-01-26 02:24:07] Using the following download hosts for Public, Realm steamglobal +[2023-01-26 02:24:07] 1. http://media.steampowered.com, /client/, Realm 'steamglobal', weight was 1, source = 'baked in' +Installing breakpad exception handler for appid(steam)/version(1671236931) +[2023-01-26 02:24:07] Checking for update on startup +[2023-01-26 02:24:08] Checking for available updates... +[2023-01-26 02:24:08] Downloading manifest: http://media.steampowered.com/client/steam_client_ubuntu12 +[2023-01-26 02:24:08] Manifest download: send request +Installing breakpad exception handler for appid(steam)/version(1671236931) +[2023-01-26 02:24:08] Manifest download: waiting for download to finish +[2023-01-26 02:24:08] Manifest download: finished +[2023-01-26 02:24:08] Download skipped: /client/steam_client_ubuntu12 version 1671236931, installed version 1671236931, existing pending version 0 +[2023-01-26 02:24:08] Nothing to do +[2023-01-26 02:24:08] Verifying installation... +[2023-01-26 02:24:08] Performing checksum verification of executable files +[2023-01-26 02:24:10] Verification complete +Loaded SDL version 2.27.0-p7692409 +Gtk-Message: 02:24:39.711: Failed to load module "gail" +Gtk-Message: 02:24:39.714: Failed to load module "atk-bridge" +XRRGetOutputInfo Workaround: initialized with override: 0 real: 0xecc479c0 +XRRGetCrtcInfo Workaround: initialized with override: 0 real: 0xecc461f0 + +(steam:17058): Gtk-WARNING **: 02:24:39.801: Unable to locate theme engine in module_path: "adwaita", +/usr/share/themes/Yaru/gtk-2.0/main.rc:775: error: unexpected identifier 'direction', expected character '}' + +(steam:17058): Gtk-WARNING **: 02:24:39.816: Unable to locate theme engine in module_path: "adwaita", +/usr/share/themes/Yaru/gtk-2.0/hacks.rc:28: error: invalid string constant "normal_entry", expected valid string constant +Fatal error: futex robust_list not initialized by pthreads +No minidump written, nothing to upload. +steamwebhelper.sh[17083]: Runtime for steamwebhelper: defaulting to /home/user/.local/share/Steam/ubuntu12_64/steam-runtime-heavy +steamwebhelper.sh[17083]: glibc >= 2.34, partially disabling sandbox until CEF supports clone3() +/home/user/.local/share/Steam/steam.sh: line 798: 17058 Segmentation fault (core dumped) "$STEAMROOT/$STEAMEXEPATH" "$@" +``` + +**System information:** + - OS: [eg: Ubuntu 21.10] Ubuntu 22.04 + - CPU/SoC: [eg: Snapdragon 888, Intel Core i8-12900k] Virtual machine on Apple M1 + - Video driver version: [eg: OpenGL ES 3.2 Mesa 22.0.0-devel (git-9ff086052a)] + - RootFS used: [eg: Ubuntu 21.10 Official Rootfs] Ubuntu 22.04 + - FEX version: (FEXGetConfig --version) [eg: FEX-2112-155-gc691d709] FEX-2301 + - Thunks Enabled: [Yes/No] + +**Additional context** + - Is this an x86 or x86-64 game: [x86/x86-64/Both] x86 + - Does this reproduce on x86-64 host with FEX: [Yes/No/Untested] Untested + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: [Yes/No/Untested] Untested + - Is this a Vulkan game: [Yes/No/Unknown] No + - If Yes, What is your Vulkan driver: + +Add any other context about the problem here. diff --git a/results/scraper/fex/2356 b/results/scraper/fex/2356 new file mode 100644 index 000000000..88e53c67a --- /dev/null +++ b/results/scraper/fex/2356 @@ -0,0 +1,5 @@ +need help automating FEXRootFSFetcher +I went back and tested my [automatic build script](https://github.com/cobalt2727/L4T-Megascript/blob/master/scripts/FEX.sh) for FEX to make sure it was still working and I've hit a roadblock - there doesn't seem to be any way to automate choosing a RootFS. Is there any way to have it always pull the latest/most recommended version without any input from the user? + + +(it doesn't even display the options if this line is run from within the script itself.) \ No newline at end of file diff --git a/results/scraper/fex/2357 b/results/scraper/fex/2357 new file mode 100644 index 000000000..f02aaa5cd --- /dev/null +++ b/results/scraper/fex/2357 @@ -0,0 +1,12 @@ +FEX fails to build on Alpine Linux (musl) +:wave: Hi! + +On Alpine Linux, trying to build FEX results in the compilation halting with the following error: +``` +/home/user/FEX/Source/Tools/FEXServer/ProcessPipe.cpp:477:60: error: use of undeclared identifier 'POLLREMOVE' + .events = POLLIN | POLLPRI | POLLRDHUP | POLLREMOVE, + ^ +``` +`POLLREMOVE` seems to come from the header `poll.h`, which I assume resolves to `/usr/include/poll.h`. `/usr/include/poll.h`, in turn, includes `<bits/poll.h>`. On Fedora with glibc, this file defines `POLLREMOVE`, but on Alpine Linux with musl it seems like this file is empty (like, completely empty) and as such `POLLREMOVE` ends up undefined. + +In the FEX 2203 changelog you mentioned musl compilation being fixed (https://fex-emu.com/FEX-2203/). How was this tested? Am I missing something? \ No newline at end of file diff --git a/results/scraper/fex/2369 b/results/scraper/fex/2369 new file mode 100644 index 000000000..94e04f2ac --- /dev/null +++ b/results/scraper/fex/2369 @@ -0,0 +1,6 @@ +global destructors in XCB thunks need to be removed +Global destructors in shared libraries aren't guaranteed to be called on dlclose but instead on exit. +In particular this is never called when Dota Underlords closes, which can cause it to hang on shutdown. +This is because the xcb::take_socket thread never exits and ends up stalling out. + +Needs some investigation as to which route will be the best to ensure that thread is always shutdown and nothing is waiting. \ No newline at end of file diff --git a/results/scraper/fex/2397 b/results/scraper/fex/2397 new file mode 100644 index 000000000..a84af6a54 --- /dev/null +++ b/results/scraper/fex/2397 @@ -0,0 +1,5 @@ +use fex-emu in android studio +hi all +I wanted to add fex-emu in android studio and create a new application (.apk) +But I don't know how to use it in Android Studio +If you have any examples or tips, please let me know \ No newline at end of file diff --git a/results/scraper/fex/2399 b/results/scraper/fex/2399 new file mode 100644 index 000000000..387cf3b7a --- /dev/null +++ b/results/scraper/fex/2399 @@ -0,0 +1,28 @@ +Mingw compilation support +This is going to require quite a bit of restructuring. + +**Step-0** +~~- [ ] Get FEXCore compiling with GCC~~ +- [x] Get FEXCore compiling with llvm-mingw + - Necessary instead of GCC path + - https://github.com/mstorsjo/llvm-mingw + +**Step-1** +- [x] Move signal context construction to Loader side +- [x] Drop frontend targets from cmake that won't ever compile with mingw +- [ ] Remove Linux-isms from FEXCore side. Using wrappers where necessary + - This is a big one, quite a few things spread around the source code +- [ ] JITs have some hardcoded assumptions here, might need to redefine some stuff so we can safely do some syscalls still +- [x] Handle SIGBUS/SIGILL FEX requirements in frontend + - Requires a collaboration between FEXCore and FEX frontend to ensure nothing unexpected shows up as a signal frame + +**Step-2** +- [ ] Introduce Build CI so we don't break it +- [ ] Introduce unittesting CI + +**Step-3** +- [ ] Integration + +**Investigation** +- [ ] How well does clang-cl or clang with a windows target work? Would be nice to not need to deal with gcc/mingw compiler problems. + - Initial testing showed linking problems that I couldn't resolve easily. \ No newline at end of file diff --git a/results/scraper/fex/2409 b/results/scraper/fex/2409 new file mode 100644 index 000000000..e0ca15ba8 --- /dev/null +++ b/results/scraper/fex/2409 @@ -0,0 +1,2 @@ +ppc64le support +It would be cool if FEX could be ported to ppc64le, e.g. [Raptor POWER9 systems](https://www.raptorcs.com/content/base/products.html). Would there be potential interest in this? \ No newline at end of file diff --git a/results/scraper/fex/2410 b/results/scraper/fex/2410 new file mode 100644 index 000000000..858336129 --- /dev/null +++ b/results/scraper/fex/2410 @@ -0,0 +1,62 @@ + x32 signal stack problem +``` c +#include <stdio.h> //printf() +#include <unistd.h> //pause() +#include <signal.h> //signal() +#include <string.h> //memset() +#include <sys/time.h> //struct itimerval, setitimer() + +static int count = 0; + +static volatile int caught_signal; + +void clear_signal(void) +{ + if (caught_signal) { + printf("caugt_signal !=0\n"); + } + while (!caught_signal); + + + if (caught_signal != SIGALRM) { + printf("Received incorrect signal: %d",caught_signal); + } + caught_signal = 0; +} + + +void printMes(int signo) +{ + caught_signal = signo; +} + +int main() +{ + int res = 0; + struct itimerval tick; + + signal(SIGALRM, printMes); + memset(&tick, 0, sizeof(tick)); + + //Timeout to run first time + tick.it_value.tv_sec = 1; + tick.it_value.tv_usec = 0; + + //After first, the Interval time for clock + tick.it_interval.tv_sec = 0; + tick.it_interval.tv_usec = 100; + + if(setitimer(ITIMER_REAL, &tick, NULL) < 0) + printf("Set timer failed!\n"); + + while(1) + { + clear_signal(); + } + return 0; +} + + +``` + +i compile this code in a ubunt16.04 x32 container. and receive segfault. diff --git a/results/scraper/fex/2417 b/results/scraper/fex/2417 new file mode 100644 index 000000000..56c32fac8 --- /dev/null +++ b/results/scraper/fex/2417 @@ -0,0 +1,2 @@ +use binfmt.d rather than binfmts for better compatibility +binfmts is only available on debian based distro. which isn't friendly to other distro. i prefer switch to [binfmt.d](https://www.freedesktop.org/software/systemd/man/binfmt.d.html) (which is a part of systemd, available on most of distro) and keep binfmts for debian only \ No newline at end of file diff --git a/results/scraper/fex/243 b/results/scraper/fex/243 new file mode 100644 index 000000000..b377f0e22 --- /dev/null +++ b/results/scraper/fex/243 @@ -0,0 +1 @@ +ninja clean fails with `Cleaning... ninja: error: remove(unittests/ASM): Directory not empty` diff --git a/results/scraper/fex/2441 b/results/scraper/fex/2441 new file mode 100644 index 000000000..a304ef670 --- /dev/null +++ b/results/scraper/fex/2441 @@ -0,0 +1,3 @@ +Archlinux ARM stuck on FEXBash under android chroot + + diff --git a/results/scraper/fex/2443 b/results/scraper/fex/2443 new file mode 100644 index 000000000..243833191 --- /dev/null +++ b/results/scraper/fex/2443 @@ -0,0 +1,5 @@ +EmulatedFiles: High CPU usage in canonicalize +https://github.com/FEX-Emu/FEX/blob/f2aa0026b58c9ec5ee56ecbf66b4f00fe01e16de/Source/Tests/LinuxSyscalls/EmulatedFiles/EmulatedFiles.cpp#L744 + +I was running AntiChamber and I saw >30% CPU time spent on this canonicalize routine during loading (which took hecking long). +We need to optimize this use case. Dropping to `realpath` is likely a good first step. Will need to run some benchmarks to see how much of an improvement that alone is and if it is worth going further. \ No newline at end of file diff --git a/results/scraper/fex/2464 b/results/scraper/fex/2464 new file mode 100644 index 000000000..8334aaef0 --- /dev/null +++ b/results/scraper/fex/2464 @@ -0,0 +1,11 @@ +ARM64JIT: Optimize Memset operation. +When switching over to the new IR operation, the primary concern was about changing IR semantics rather than optimizing. + +With inline constant on the IR operation we can detect zero being stored and optimize to `DC ZVA`, but also we can do the same optimization that compilers do and unwind the loop to 128-bit stores on the non-TSO variant. Getting closer to native memset perf is ideal. + +And additional step in the future will be to have an additional optimization in order to use the new MOPS instructions that ARM provides. + + +[ ] - Loop unwind (Only need to have a tight 128-bit loop. Enough to saturate the store pipelines) +[ ] - DC ZVA optimization +[ ] - ARM MOPS implementation diff --git a/results/scraper/fex/2472 b/results/scraper/fex/2472 new file mode 100644 index 000000000..10e244407 --- /dev/null +++ b/results/scraper/fex/2472 @@ -0,0 +1,2 @@ +Generated IROp_Header is not properly aligned +In #2319 hasDest is removed from struct IROp_Header, which makes IROp_Header 3 bytes in total. Since all IR structs are packed, and referenced IROp_Header, which makes them all un-aligned. This could: 1. have performance impact on IR emitting. 2. breaks some compilers like clang in NDK (which addes 1 byte padding in derived IROp_XXX structures). \ No newline at end of file diff --git a/results/scraper/fex/2487 b/results/scraper/fex/2487 new file mode 100644 index 000000000..16555da79 --- /dev/null +++ b/results/scraper/fex/2487 @@ -0,0 +1,51 @@ +Guest long jump out of signal handler doesn't reset host stack location +Simple example: +```cpp +#include <csetjmp> +#include <cstddef> +#include <cstdint> +#include <unistd.h> +#include <stdio.h> +#include <sys/mman.h> +#include <sys/signal.h> +#include <vector> +#include <thread> + +static std::jmp_buf longjump{}; +int Result; + +static void SignalHandler(int Signal, siginfo_t *info, void *context) { + std::longjmp(longjump, 1); +} + +static void Thread() { + struct sigaction act{}; + act.sa_sigaction = SignalHandler; + act.sa_flags = SA_SIGINFO | SA_NODEFER; + sigaction(SIGSEGV, &act, nullptr); + + size_t DataSize = 16 * 4096; + void *Data = mmap(nullptr, DataSize, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + + setjmp(longjump); + + // This will infinite SIGSEGV now through the signal handler. + Result = ((int*)Data)[0]; +} + +int main() { + std::thread t(Thread); + t.join(); + return Result; +} +``` + +This run under FEX will eventually overrun the host stack, and also the host stacks sigaltstack, and then infinitely loop through the host alt-stack. It spins up a thread to ensure our host thread is one of the threads with an 8MB stack rather than the primary which has 128MB. + +We can't capture long jump since on x86 this is purely a userspace construct. +This is likely only a problem if the guest signal handler is set with NODEFER since otherwise the signal gets masked and long jumping out means the mask doesn't get updated again and they won't receive the signal again...Although I guess multiple signals could be affecting each other so NODEFER isn't the only viable option to know when this can occur? + +Maybe we store guest stack frame locations on signal and then on the next signal see if the the guest has rewound the stack past the previous stored? If rewound then unwind the host stack similar to how we previously unwound the stack with the interpreter? Might get a little weird to unwind frames that live outside of the JIT. Also we don't currently store where our host stack lives, so we would need need to store guest stack location plus the host stack location which we currently store on the guest stack. + +I believe a game that uses this behaviour is moon-buggy. If it wasn't that one then it is one of the other games from the bsdgames package. +Noticed this while working on deferred signals and thought that I was going to change behaviour but turned out this was already broken. \ No newline at end of file diff --git a/results/scraper/fex/2488 b/results/scraper/fex/2488 new file mode 100644 index 000000000..5c058f857 --- /dev/null +++ b/results/scraper/fex/2488 @@ -0,0 +1,47 @@ +Build Bug: "Cannot find -lgcc" +When configuring `guest-libs-32`, I get this error message: +``` +[352/522] Performing configure step for 'guest-libs-32' +FAILED: guest-libs-32/src/guest-libs-32-stamp/guest-libs-32-configure +cd /FEX/Build/Guest_32 && /usr/bin/cmake -DBITNESS=32 -DCMAKE_BUILD_TYPE=RELEASE -DENABLE_CLANG_THUNKS=OFF -DCMAKE_TOOLCHAIN_FILE:FILEPATH=/FEX/toolchain_x86_32.cmake -DCMAKE_INSTALL_PREFIX=/usr -DSTRUCT_VERIFIER=/FEX/Scripts/StructPackVerifier.py -DFEX_PROJECT_SOURCE_DIR=/FEX -DGENERATOR_EXE=/FEX/Build/Bin/thunkgen -GNinja /FEX/ThunkLibs/GuestLibs && /usr/bin/cmake -E touch /FEX/Build/guest-libs-32/src/guest-libs-32-stamp/guest-libs-32-configure +-- The C compiler identification is GNU 10.2.1 +-- The CXX compiler identification is GNU 10.2.1 +-- Detecting C compiler ABI info +-- Detecting C compiler ABI info - failed +-- Check for working C compiler: /bin/x86_64-linux-gnu-gcc +-- Check for working C compiler: /bin/x86_64-linux-gnu-gcc - broken +CMake Error at /usr/share/cmake-3.18/Modules/CMakeTestCCompiler.cmake:66 (message): + The C compiler + + "/bin/x86_64-linux-gnu-gcc" + + is not able to compile a simple test program. + + It fails with the following output: + + Change Dir: /FEX/Build/Guest_32/CMakeFiles/CMakeTmp + + Run Build Command(s):/bin/ninja cmTC_e03c7 && [1/2] Building C object CMakeFiles/cmTC_e03c7.dir/testCCompiler.c.o + [2/2] Linking C executable cmTC_e03c7 + FAILED: cmTC_e03c7 + : && /bin/x86_64-linux-gnu-gcc -m32 CMakeFiles/cmTC_e03c7.dir/testCCompiler.c.o -o cmTC_e03c7 && : + /usr/lib/gcc-cross/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc-cross/x86_64-linux-gnu/10/libgcc.a when searching for -lgcc + /usr/lib/gcc-cross/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/bin/ld: cannot find -lgcc + /usr/lib/gcc-cross/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc-cross/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/lib/libgcc_s.so.1 when searching for libgcc_s.so.1 + /usr/lib/gcc-cross/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/bin/ld: cannot find libgcc_s.so.1 + /usr/lib/gcc-cross/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc-cross/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/lib/libgcc_s.so.1 when searching for libgcc_s.so.1 + /usr/lib/gcc-cross/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc-cross/x86_64-linux-gnu/10/libgcc.a when searching for -lgcc + /usr/lib/gcc-cross/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/bin/ld: cannot find -lgcc + collect2: error: ld returned 1 exit status + ninja: build stopped: subcommand failed. + + + + + + CMake will not be able to correctly generate this project. +Call Stack (most recent call first): + CMakeLists.txt:2 (project) +``` + +This is on a Debian bullseye system. diff --git a/results/scraper/fex/2489 b/results/scraper/fex/2489 new file mode 100644 index 000000000..c177c0345 --- /dev/null +++ b/results/scraper/fex/2489 @@ -0,0 +1,75 @@ +Ninja failing on Step 71/346 +I have installed all the possible prerequisites on the install page and I am running Armbian, a modified version of Debian. uname -a yields: + +```bash +Linux rock-5b 5.10.110-rockchip-rk3588 #23.02.2 SMP Fri Feb 17 23:59:20 UTC 2023 aarch64 GNU/Linux +``` + +```bash +CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DENABLE_LTO=True -DENABLE_LLD=True -DBUILD_TESTS=False -DENABLE_ASSERTIONS=False -G Ninja .. +``` +Works and gets this output: +```bash +-- The C compiler identification is Clang 11.0.1 +-- The CXX compiler identification is Clang 11.0.1 +-- Detecting C compiler ABI info +-- Detecting C compiler ABI info - done +-- Check for working C compiler: /usr/bin/clang - skipped +-- Detecting C compile features +-- Detecting C compile features - done +-- Detecting CXX compiler ABI info +-- Detecting CXX compiler ABI info - done +-- Check for working CXX compiler: /usr/bin/clang++ - skipped +-- Detecting CXX compile features +-- Detecting CXX compile features - done +-- Looking for include file gdb/jit-reader.h +-- Looking for include file gdb/jit-reader.h - not found +-- CCache enabled +-- Performing Test ENUM_ENUM_WARNING +-- Performing Test ENUM_ENUM_WARNING - Success +-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2") +-- Found Python: /usr/bin/python3.9 (found suitable version "3.9.2", minimum required is "3.0") found components: Interpreter +-- Module support is disabled. +-- Version: 9.0.0 +-- Build type: RELEASE +-- CXX_STANDARD: 20 +-- Performing Test has_std_20_flag +-- Performing Test has_std_20_flag - Success +-- Performing Test has_std_2a_flag +-- Performing Test has_std_2a_flag - Success +-- Required features: cxx_variadic_templates +-- Performing Test HAS_NULLPTR_WARNING +-- Performing Test HAS_NULLPTR_WARNING - Success +-- Performing Test GCC_COLOR +-- Performing Test GCC_COLOR - Success +-- Performing Test CLANG_COLOR +-- Performing Test CLANG_COLOR - Success +-- Performing Test COMPILER_SUPPORTS_CPU_TYPE +-- Performing Test COMPILER_SUPPORTS_CPU_TYPE - Success +-- Performing Test compiles +-- Performing Test compiles - Success +-- Has getcpu helper +-- Has gettid helper +-- Has tgkill helper +-- Has statx helper +-- Has renameat2 helper +-- Found Git: /usr/bin/git (found version "2.30.2") +-- Configuring done +-- Generating done +-- Build files have been written to: /home/zach/Downloads/FEX/Build +``` + +After this I run the ninja for building and get the following: +```bash +[0/2] Re-checking globbed directories... +[71/346] Linking CXX s...arse/libcpp-optparse.a +FAILED: External/cpp-optparse/libcpp-optparse.a +: && /usr/bin/cmake -E rm -f External/cpp-optparse/libcpp-optparse.a && "CMAKE_CXX_COMPILER_AR-NOTFOUND" cr External/cpp-optparse/libcpp-optparse.a External/cpp-optparse/CMakeFiles/cpp-optparse.dir/OptionParser.cpp.o && "CMAKE_CXX_COMPILER_RANLIB-NOTFOUND" External/cpp-optparse/libcpp-optparse.a && : +/bin/sh: 1: CMAKE_CXX_COMPILER_AR-NOTFOUND: not found +[80/346] Linking C sta...nal/xxhash/libxxhash.a +FAILED: External/xxhash/libxxhash.a +: && /usr/bin/cmake -E rm -f External/xxhash/libxxhash.a && "CMAKE_C_COMPILER_AR-NOTFOUND" cr External/xxhash/libxxhash.a External/xxhash/CMakeFiles/xxhash.dir/xxhash.c.o && "CMAKE_C_COMPILER_RANLIB-NOTFOUND" External/xxhash/libxxhash.a && : +/bin/sh: 1: CMAKE_C_COMPILER_AR-NOTFOUND: not found +ninja: build stopped: subcommand failed. +``` +Any ideas on what is causing this and how to fix it? I am running on a ROCK 5b with the Rockchip 3588. \ No newline at end of file diff --git a/results/scraper/fex/25 b/results/scraper/fex/25 new file mode 100644 index 000000000..a42155482 --- /dev/null +++ b/results/scraper/fex/25 @@ -0,0 +1,2 @@ +Make CI runner actually push artifacts to the shared folder +`Date/Hash/Runner` folder structure sort of thing. \ No newline at end of file diff --git a/results/scraper/fex/2500 b/results/scraper/fex/2500 new file mode 100644 index 000000000..6818ebdbe --- /dev/null +++ b/results/scraper/fex/2500 @@ -0,0 +1,59 @@ +FEX needs to drop std:: in favour of fextl:: +# Whhhhhhhhhhhy?! +- FEX needs to stop replacing the glibc allocator with jemalloc + +# But just use std::allocators +- That's what fextl:: is. Vetted std:: containers that replace the allocator with FEX's allocator by default + +# Whhhhhhhhhhhy?! +To ease mental burden about thinking if a std:: class has been vetted to not allocate memory outside of FEX's allocator + +# Why does FEX need to control how memory is allocated? +All of FEX's allocations take up precious virtual address space, when FEX is running a a 32-bit application it will consume all 64-bit VA space then allocate out of it. +FEX currently uses jemalloc's glibc hooking to replace the global allocator to let the guest application consume the remaining space. + +# Why not just keep using that? +FEX's thunking system is also affected by the global glibc allocator since the jemalloc replacement extends to anything that we dlopen. In the case of 32-bit thunking, this would mean that pointers returned by libGL and libVulkan would only ever be in the 64-bit VA space. + +# Okay, we need to stop replacing the glibc allocator then? That's easy. Why fextl? +You're right, if we stop replacing the glibc allocator then that will no longer be an issue. We then have a different issue. +FEX allocates a lot of memory (Mostly virtual, some resident), this takes up virtual address space. When running a 32-bit application this will mean FEX quickly exhausts the 4GB of virtual address space that the 32-bit application has. + +This problem can be seen today by disabling JEMalloc and trying to run Steam, it will almost immediately run out of memory. + +# Well stop using so much memory +Never. + +But really, 32-bit games without emulation already run out of memory and we need to stay out of their way as much as physically possible. + +# How will this be enforced? +A new CI option will hook the glibc allocators and immediately fault if something tries allocating memory outside of FEX's allocator. +This will be put in place once FEX is "glibc allocator clean". + +# What if I want to use something in the `std::` namespace that isn't in `fextl::` +Vet it to make sure it doesn't allocate memory and then create an alias. It lowers mental burden when needing to think "Does this one-off use case of std:: allocate memory or not?" + +# What about things in the `std::` namespace that allocate memory and don't have a way to replace the allocator? +This is why we have CI to ensure this. If you're using unvetted `std::` and then try aliasing it by adding a `fextl::` version, CI should ensure that it doesn't allocate memory. +There are some known bad `std::` namespace functions that allocate memory regardless of what we do and should be avoided. + +## Non exhaustive list: +- std::filesystem::path +- std::filesystem::absolute +- std::filesystem::canonical +- std::fstream + +# What about things not in the `std::` namespace that allocate memory? +Same thing as before, these should be avoid at all cost and hopefully CI should catch it. We will be on the lookout for these, work on removing them, and make sure CI can capture someone trying to add this in the future + +## Non exhaustive list +- get_nprocs_conf +- getcwd +- strerror + - This one is particularly annoying because it allocates memory for locales. + +# What if something just temporarily allocates memory? +We really don't want to allow this since it just means that everyone can just say "well this allocates memory temporarily so it's not an issue". That's not the case, any sort of allocations is highly likely to impact the 32-bit VA space and can easily run out of memory. + +...But if we /really/ need to, we can add an escape hatch so there are some sections in CI that hit this and won't fault. +But I'm going to complain very loudly every. single. time. one of these get added and they better have a good justification. \ No newline at end of file diff --git a/results/scraper/fex/2548 b/results/scraper/fex/2548 new file mode 100644 index 000000000..bb61a7f54 --- /dev/null +++ b/results/scraper/fex/2548 @@ -0,0 +1,11 @@ +DX11 apps in Wine hangs randomly +Hello, first I would like to thank you for your great work! +I'm now working on a project which aims to run Wine natively on Android devices. We use both FEX-Emu and box64 as emulator backend. Now we can successfully boot into wine desktop with both emulator backends. + +During our test, we found certain DX11 apps hangs at startup with FEX-Emu, stack trace shows most threads are blocked by futex_wait syscall. after trying with different config combinations, it seems adding multiblock could greatly reduce the chance of hang. This hang happens only with FEX-emu, not with box64 or runs directly on x86 machine. + +The attachment is the DX11 app, extract the archive to c:\, run c:\directx\directx\nbodygravitycs11.exe, I can easily reproduce the hang. + +My test environment is wine 7.0, dxvk 1.10.3, fex-emu 2303, runs on OnePlus 11, Android 13. +P.S. Since I have patched fex-emu and wrote thunk libs to make it run on Android, I have considered the root cause could be in my patch. However my 3588 board still need sometime to arrive, so I think I could post it here, hoping people with capable hardware could help test it for me. +[DirectX.zip](https://github.com/FEX-Emu/FEX/files/11003291/DirectX.zip) diff --git a/results/scraper/fex/2550 b/results/scraper/fex/2550 new file mode 100644 index 000000000..06e2dfa00 --- /dev/null +++ b/results/scraper/fex/2550 @@ -0,0 +1,51 @@ +[Maybe bug] curl-amd64: (16) Send failure: Broken pipe +In my amd64 debian machine: +``` +$ wget https://github.com/moparisthebest/static-curl/releases/download/v7.88.1/curl-amd64 +$ ./curl-amd64 https://1.1.1.1 | head -n 20 +//It can show the correct 1.1.1.1 logo + +$ scp curl-amd64 root@192.168.0.2:/root/ +//scp it into my arm64 armbian machine 192.168.0.2 +``` + +In my arm64 armbian machine: +(I see there's an aarch64 version of static-curl, here I'm just finding a simplest way to test fex-emu environment) +``` +$ curl --silent https://raw.githubusercontent.com/FEX-Emu/FEX/main/Scripts/InstallFEX.py --output /tmp/InstallFEX.py && python3 /tmp/InstallFEX.py && rm /tmp/InstallFEX.py +//successfully installed fex-emu +$ FEXInterpreter ./curl-amd64 -V +curl 7.88.1 (x86_64-pc-linux-musl) libcurl/7.88.1 OpenSSL/1.1.1t zlib/1.2.12 libssh2/1.10.0 nghttp2/1.47.0 +Release-Date: 2023-02-20 +Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp +Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL threadsafe TLS-SRP UnixSockets + +$ FEXInterpreter ./curl-amd64 -v https://1.1.1.1 +* Trying 1.1.1.1:443... +* Connected to 1.1.1.1 (1.1.1.1) port 443 (#0) +* ALPN: offers h2,http/1.1 +* TLSv1.3 (OUT), TLS handshake, Client hello (1): +* CAfile: /etc/ssl/certs/ca-certificates.crt +* CApath: none +* TLSv1.3 (IN), TLS handshake, Server hello (2): +* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): +* TLSv1.3 (IN), TLS handshake, Certificate (11): +* TLSv1.3 (IN), TLS handshake, CERT verify (15): +* TLSv1.3 (IN), TLS handshake, Finished (20): +* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): +* TLSv1.3 (OUT), TLS handshake, Finished (20): +* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 +* ALPN: server accepted h2 +* Server certificate: +* subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=cloudflare-dns.com +* start date: Jan 12 00:00:00 2023 GMT +* expire date: Jan 11 23:59:59 2024 GMT +* subjectAltName: host "1.1.1.1" matched cert's IP address! +* issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1 +* SSL certificate verify ok. +* Send failure: Broken pipe +* OpenSSL SSL_write: Broken pipe, errno 32 +* Closing connection 0 +curl: (16) Send failure: Broken pipe +``` +Maybe there's a bug in fex-emu about network socket, any hint? \ No newline at end of file diff --git a/results/scraper/fex/2551 b/results/scraper/fex/2551 new file mode 100644 index 000000000..80674de4b --- /dev/null +++ b/results/scraper/fex/2551 @@ -0,0 +1,15 @@ +"FEXServerClient: Failure to setup client" while run curso.so on armbian +Trying to run Cursor editor in armbian: +download Cursor-0.1.0.AppImage from https://cursor.so +``` +$ chmod 744 Cursor-0.1.0.AppImage +$ ./Cursor-0.1.0.AppImage --appimage-extract +$ cd squashfs-root +$ FEXInterpreter ./AppRun +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 111 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the process +[ERROR] FEXServerClient: Failure to setup client +Trace/breakpoint trap +``` + +Any hint ? diff --git a/results/scraper/fex/2553 b/results/scraper/fex/2553 new file mode 100644 index 000000000..2923963c5 --- /dev/null +++ b/results/scraper/fex/2553 @@ -0,0 +1,33 @@ +FEXBash SteamCMD +What Game +installing the steamcmd for conan exiles server + +Describe the bug +Trying to install steamcmd but get error + +To Reproduce +Steps to reproduce the behavior: + +Usage examples: +# steam is a bash script. Wrap with FEXBash + FEXBash steam +# Full path execution execution will wrap the application if it exists in the rootfs + FEXInterpreter /usr/bin/uname +# Freestanding x86/x86-64 programs can be executed directly. binfmt_misc will redirect to FEX + $HOME/PetalCrashOnline.AppImage +# If you need a terminal that emulates everything. +# Run FEXBash without arguments. Double check uname to see if running under FEX + FEXBash +ubuntu@conanpveexiles:~$ FEXBash steam +/run/user/1001/.FEXMount7357-ZibRfl/bin/sh: 1: steam: not found +ubuntu@conanpveexiles:~$ +ubuntu@conanpveexiles:~$ FEXBash +FEXBash-ubuntu@conanpveexiles:~> sudo apt-get install steamcmd +Reading package lists... Done +Building dependency tree... Done +Reading state information... Done +Package steamcmd is not available, but is referred to by another package. +This may mean that the package is missing, has been obsoleted, or +is only available from another source + +E: Package 'steamcmd' has no installation candidate diff --git a/results/scraper/fex/2560 b/results/scraper/fex/2560 new file mode 100644 index 000000000..681eb5aaa --- /dev/null +++ b/results/scraper/fex/2560 @@ -0,0 +1,2 @@ +VC redistributables still crash loop +For some reason these still crash loop depending on the exact version. Nailing down why might be a bit difficult. \ No newline at end of file diff --git a/results/scraper/fex/2561 b/results/scraper/fex/2561 new file mode 100644 index 000000000..47c161a1b --- /dev/null +++ b/results/scraper/fex/2561 @@ -0,0 +1,80 @@ +BEXTR concerns (formerly "shift thoughts") +Sorry if these are incorrect or already on the to-do list. Feel free to ignore it, but I was just reading the code and figured this might be helpful. + +--- + +[DONE] I noticed a lot of comments saying "x86 masks the shift by 0x3F or 0x1F depending on size of op", followed by emitting AND operations. + +https://github.com/FEX-Emu/FEX/blob/fea0162/External/FEXCore/Source/Interface/Core/OpcodeDispatcher.cpp#L2075-L2080 + +```cpp + // x86 masks the shift by 0x3F or 0x1F depending on size of op + if (Size == 64) { + Src = _And(Src, _Constant(Size, 0x3F)); + } else { + Src = _And(Src, _Constant(Size, 0x1F)); + } +``` + +AArch64 has the same masking behaviour, so this seems unnecessary? (Though I'm not sure about the IR semantics, and maybe this is optimised out later anyway, or helpful for computing flags or something). + +--- + +[DONE] SVE has [shifts where "the shift amount operand is a vector of unsigned elements in which all bits are significant"](https://developer.arm.com/documentation/ddi0596/2021-12/SVE-Instructions/LSL--vectors---Logical-shift-left-by-vector--predicated--), seemingly matching AVX, which would make the DUP/UMIN unnecessary: + +https://github.com/FEX-Emu/FEX/blob/fea0162/External/FEXCore/Source/Interface/Core/JIT/Arm64/VectorOps.cpp#L2102-L2108 + +```cpp + const auto Mask = PRED_TMP_32B.Merging(); + + dup_imm(SubRegSize, VTMP2.Z(), MaxShift); + umin(SubRegSize, VTMP2.Z(), Mask, VTMP2.Z(), ShiftVector.Z()); + + movprfx(Dst.Z(), Vector.Z()); + lsl(SubRegSize, Dst.Z(), Mask, Dst.Z(), VTMP2.Z()); +``` + +--- + +[DONE] On the Adv.SIMD side, I figured I'd mention that you can clamp the 64-bit shift amount using UQSHL + USHR, saving a couple of instructions. (That also works for smaller element sizes, but the latency is worse than the current MOVI + UMIN.) + +https://github.com/FEX-Emu/FEX/blob/fea0162/External/FEXCore/Source/Interface/Core/JIT/Arm64/VectorOps.cpp#L2110-L2122 + +```cpp + if (ElementSize < 8) { + movi(SubRegSize, VTMP1.Q(), MaxShift); + umin(SubRegSize, VTMP1.Q(), VTMP1.Q(), ShiftVector.Q()); + } else { + LoadConstant(ARMEmitter::Size::i64Bit, TMP1, MaxShift); + dup(SubRegSize, VTMP1.Q(), TMP1.R()); + + // UMIN is silly on Adv.SIMD and doesn't have a variant that handles 64-bit elements + cmhi(SubRegSize, VTMP2.Q(), ShiftVector.Q(), VTMP1.Q()); + bif(VTMP1.Q(), ShiftVector.Q(), VTMP2.Q()); + } + + ushl(SubRegSize, Dst.Q(), Vector.Q(), VTMP1.Q()); +``` + +--- + +And finally your BEXTR looks a little suspicious: + +https://github.com/FEX-Emu/FEX/blob/fea0162/External/FEXCore/Source/Interface/Core/OpcodeDispatcher.cpp#L2309-L2321 +```cpp + // Now handle the length specifier. + auto Length = _Bfe(8, 8, Src2); + auto SanitizedLength = _Select(IR::COND_ULE, + Length, MaxSrcBitOp, + Length, MaxSrcBitOp); + + // Now build up the mask + // (1 << SanitizedLength) - 1 + auto One = _Constant(SrcSize, 1); + auto Mask = _Sub(_Lshl(One, SanitizedLength), One); + + // Now put it all together and make the result. + auto Dest = _And(SanitizedShifted, Mask); +``` + +Length is sanitised so it's at most SrcSize-1, but I believe BEXTR allows you to specify length=SrcSize and start=0, and get the whole register unchanged? (Unfortunately I can't see a way to support both that and length=0 without adding instructions.) \ No newline at end of file diff --git a/results/scraper/fex/2562 b/results/scraper/fex/2562 new file mode 100644 index 000000000..7ebba3107 --- /dev/null +++ b/results/scraper/fex/2562 @@ -0,0 +1,2 @@ +Unnecessary heap-allocations in StringConv.h +e.g. `static fextl::string LeftTrim(fextl::string String, fextl::string TrimTokens = " \t\n\r") {` will heap-allocate memory for the TrimTokens. \ No newline at end of file diff --git a/results/scraper/fex/2563 b/results/scraper/fex/2563 new file mode 100644 index 000000000..80126a5e0 --- /dev/null +++ b/results/scraper/fex/2563 @@ -0,0 +1,175 @@ +Scalar vector performance issues with FMOD +FMOD burns a CPU core, specifically in Hollow Knight's title screen. Seems to be a little loop that spins really hot that we don't optimize well. It's bad enough that a ton of Unity+FMOD games will stutter their audio quite hard. + +This is due to how the code is using a loop-unrolled scalar FMA to process audio blocks and FEX converting the code badly. + +Original code. +```asm +01aaf061 89ce mov esi, ecx +01aaf063 4889ea mov rdx, rbp +01aaf066 4889d8 mov rax, rbx + +01aaf069 f30f1012 movss xmm2, dword [rdx] +01aaf06d 4883c020 add rax, 0x20 +01aaf071 f30f59d0 mulss xmm2, xmm0 +01aaf075 4883c220 add rdx, 0x20 +01aaf079 f30f5850e0 addss xmm2, dword [rax-0x20] +01aaf07e f30f1150e0 movss dword [rax-0x20], xmm2 +01aaf083 f30f1052e4 movss xmm2, dword [rdx-0x1c] +01aaf088 f30f59d1 mulss xmm2, xmm1 +01aaf08c f30f5850e4 addss xmm2, dword [rax-0x1c] +01aaf091 f30f1150e4 movss dword [rax-0x1c], xmm2 +01aaf096 f30f1052e8 movss xmm2, dword [rdx-0x18] +01aaf09b f30f59d0 mulss xmm2, xmm0 +01aaf09f f30f5850e8 addss xmm2, dword [rax-0x18] +01aaf0a4 f30f1150e8 movss dword [rax-0x18], xmm2 +01aaf0a9 f30f1052ec movss xmm2, dword [rdx-0x14] +01aaf0ae f30f59d1 mulss xmm2, xmm1 +01aaf0b2 f30f5850ec addss xmm2, dword [rax-0x14] +01aaf0b7 f30f1150ec movss dword [rax-0x14], xmm2 +01aaf0bc f30f1052f0 movss xmm2, dword [rdx-0x10] +01aaf0c1 f30f59d0 mulss xmm2, xmm0 +01aaf0c5 f30f5850f0 addss xmm2, dword [rax-0x10] +01aaf0ca f30f1150f0 movss dword [rax-0x10], xmm2 +01aaf0cf f30f1052f4 movss xmm2, dword [rdx-0xc] +01aaf0d4 f30f59d1 mulss xmm2, xmm1 +01aaf0d8 f30f5850f4 addss xmm2, dword [rax-0xc] +01aaf0dd f30f1150f4 movss dword [rax-0xc], xmm2 +01aaf0e2 f30f1052f8 movss xmm2, dword [rdx-0x8] +01aaf0e7 f30f59d0 mulss xmm2, xmm0 +01aaf0eb f30f5850f8 addss xmm2, dword [rax-0x8] +01aaf0f0 f30f1150f8 movss dword [rax-0x8], xmm2 +01aaf0f5 f30f1052fc movss xmm2, dword [rdx-0x4] +01aaf0fa f30f59d1 mulss xmm2, xmm1 +01aaf0fe f30f5850fc addss xmm2, dword [rax-0x4] +01aaf103 f30f1150fc movss dword [rax-0x4], xmm2 +01aaf108 83ee01 sub esi, 0x1 +01aaf10b 0f8558ffffff jne 0x1aaf069 +``` +Single step of the job: +``` asm +00010029 f30f1052e0 movss xmm2, dword [rdx-0x20] +0001002e f30f59d0 mulss xmm2, xmm0 +00010032 f30f5850e0 addss xmm2, dword [rax-0x20] +00010037 f30f1150e0 movss dword [rax-0x20], xmm2 +``` + +Resulting AArch64 asm +```asm + 0x0000ffffe2d000bc: ldur s18, [x6, #-32] + 0x0000ffffe2d000c0: fmul s4, s18, s16 + 0x0000ffffe2d000c4: mov v18.s[0], v4.s[0] + 0x0000ffffe2d000c8: ldur s4, [x4, #-32] + 0x0000ffffe2d000cc: fadd s4, s18, s4 + 0x0000ffffe2d000d0: mov v18.s[0], v4.s[0] + 0x0000ffffe2d000d4: eor v0.16b, v0.16b, v0.16b + 0x0000ffffe2d000d8: mov v0.s[0], v18.s[0] + 0x0000ffffe2d000dc: mov v4.16b, v0.16b + 0x0000ffffe2d000e0: stur s4, [x4, #-32] +``` + +Ideally the AArch64 asm should be: +```asm +ldur s18, [x6, #-32] +fmul s18, s18, s16 +ldur s4, [x4, #-32] +fadd s18, s18, s4 +stur s18, [x4, #-32] +``` + +IPC numbers are trash according to llvm-mca: +```bash +ryanh@ubuntu-linux-20-04-desktop:~$ llvm-mca -mcpu=cortex-a57 test.s +Iterations: 100 +Instructions: 1000 +Total Cycles: 3214 +Total uOps: 1300 + +Dispatch Width: 3 +uOps Per Cycle: 0.40 +IPC: 0.31 +Block RThroughput: 5.0 +``` + +Theoretical improvements: +```bash +ryanh@ubuntu-linux-20-04-desktop:~$ llvm-mca -mcpu=cortex-a57 test_opt.s +Iterations: 100 +Instructions: 500 +Total Cycles: 217 +Total uOps: 500 + +Dispatch Width: 3 +uOps Per Cycle: 2.30 +IPC: 2.30 +Block RThroughput: 2.0 +``` + + +Sample FEX ASM unit test that can see the issue looking at the generated code. +```asm + +; This is based on the hottest block of Unity+FMOD's audio code from Hollow Knight +; This is doing some sort of unrolled scalar FMA that works on a full block at a time + +; xmm0 contains one channel multiplication value +; xmm1 contains the other channel? +; These come from arguments +movss xmm0, dword [rel scalar_val] +movss xmm1, dword [rel scalar_val2] + +; Break the block to be closer to original block +jmp local +local: + +; RAX contains the source block of data. Each block containing 32-bytes of data +; The data is modified in-place +; Data format +; struct Data { +; float data; +; float adder; +; } +mov rax, 0xe8000000 +; ESI contains the number of blocks to operate on, Only one block in this test +mov esi, 1 +; RDX contains the source value to multiply by +mov rdx, 0xe8000020 + +top: + +add rax, 0x20 ; Increment Source block +add rdx, 0x20 ; Increment multiplier stereo blocks + +; Do the remainder in a repeating macro +%macro OneChannelUnroll 2 +; Load chan1 + movss xmm2, dword [rdx - %1] +; Multiply chan1 by channel multiplier + mulss xmm2, %2 +; Add to data source and store back to memory + addss xmm2, dword [rax - %1] + movss dword [rax - %1], xmm2 +%endmacro + +; Channel 1 +OneChannelUnroll 0x20, xmm0 +; Channel 2 +OneChannelUnroll 0x1c, xmm1 + +;OneChannelUnroll 0x18, xmm0 +;OneChannelUnroll 0x14, xmm1 +;OneChannelUnroll 0x10, xmm0 +;OneChannelUnroll 0x0c, xmm1 +;OneChannelUnroll 0x08, xmm0 +;OneChannelUnroll 0x04, xmm1 + +sub esi, 1 +jne top + +hlt + +scalar_val: +dd 1.0 +scalar_val2: +dd 1.0 +``` \ No newline at end of file diff --git a/results/scraper/fex/2565 b/results/scraper/fex/2565 new file mode 100644 index 000000000..319d649a6 --- /dev/null +++ b/results/scraper/fex/2565 @@ -0,0 +1,6 @@ +can't dlopen: libFEXCore.so: cannot allocate memory in static TLS block +Hi, +I'd like to use libFEXCore in Hangover ( https://github.com/AndreRH/hangover/ ), but a major blocker is that I can't dlopen it. +The message "libFEXCore.so: cannot allocate memory in static TLS block" seems to indicate that the library want's to use more TLS memory than statically available, but even if I (for testing purposes) remove all thread_locals from libFEXCore, I get the same message. Any idea? + +Note that using LD_PRELOAD works for a test application, but won't be viable for Hangover/Wine \ No newline at end of file diff --git a/results/scraper/fex/2567 b/results/scraper/fex/2567 new file mode 100644 index 000000000..1942b6d70 --- /dev/null +++ b/results/scraper/fex/2567 @@ -0,0 +1,18 @@ +Error opening steam 19772 Illegal instruction +``` +$ FEXBash steam +erofsfuse 1.6 +disk: /home/benja/.fex-emu/RootFS/Ubuntu_22_10.ero +offset: 0 +mountpoint: /run/user/1000/.FEXMount19624-kmrhr3 +dbglevel: 0 +steam.sh[19631]: Running Steam on ubuntu 22.10 64-bit +steam.sh[19631]: STEAM_RUNTIME is enabled automatically +setup.sh[19711]: Steam runtime environment up-to-date! +steam.sh[19631]: Can't find 'steam-runtime-check-requirements', continuing anyway +[2023-03-27 13:41:14] Startup - updater built Feb 14 2023 00:47:09 +[2023-03-27 13:41:14] Startup - Steam Client launched with: '/home/benja/.local/share/Steam/ubuntu12_32/steam' +No minidump written, nothing to upload. +/home/benja/.local/share/Steam/steam.sh: line 798: 19772 Illegal instruction (core dumped) "$STEAMROOT/$STEAMEXEPATH" "$@" +``` +Dumps are empty and i have no idea what i need to do to fix this \ No newline at end of file diff --git a/results/scraper/fex/2573 b/results/scraper/fex/2573 new file mode 100644 index 000000000..32e68d24f --- /dev/null +++ b/results/scraper/fex/2573 @@ -0,0 +1,5 @@ +Crash Bandicoot 4 uses `PCMPESTRI` unconditionally. +First game I have found that uses it even when SSE4.2 CPUID bit isn't exposed. +Steam page: https://store.steampowered.com/app/1378990/Crash_Bandicoot_4_Its_About_Time/ + +Likely want to implement this initially as a C fallback, but there should be some investigation in to optimizing it to SVE MATCH plus predicate twiddling since even with SVE-128bit it might be more optimal. \ No newline at end of file diff --git a/results/scraper/fex/2589 b/results/scraper/fex/2589 new file mode 100644 index 000000000..e2c8ded72 --- /dev/null +++ b/results/scraper/fex/2589 @@ -0,0 +1,191 @@ +Linux kernel uprev UAPI investigations +FEX currently exposes kernel version up to 5.18. Need to investigate UAPI changes to ensure it's safe to uprev. + +- 5.19 + - Seems fine without any changes. + - Detected Changes + - si_perf_flags added to siginfo. FEX doesn't support. + - SO_RCVMARK Added to socket. FEX never touches + - agpgart changes. FEX doesn't support. + - BPF added some stuff. FEX doesn't support. + - io_uring changing some structs. Strictly padded so will just work. + - io_uring async ioctls added. FEX doesn't have coverage. Should just work. + - landlock added a bit. FEX doesn't care. + - Syscalls + - None added. + - DRM + - Already handled. +- 6.0 + - Seems fine without any changes. + - Detected Changes + - BPF added some stuff. FEX doesn't support. + - dma_buf added two new ioctls. FEX doesn't have coverage. Should just work. + - io_uring added more flags. Should just work. + - v4l2 has some new structs. No coverage. So if it is broken we wouldn't know anyway. Not like x86 apps care about v4l2. + - HabanaLabs added some stuff. Don't care if it is broken. + - Syscalls + - None added. + - DRM + - Already handled. +- 6.1 + - Seems fine without any changes. + - Detected Changes + - MADV_COLLAPSE added. Will just work. + - Panfrost added some userspace coredump stuff. Looks padded fine. + - More BPF stuff. + - io_uring added a couple things. Should just work. + - Syscalls + - None added. + - DRM + - Already handled. +- 6.2 + - Seems fine without any changes. + - Detected Changes + - BPF added more stuff again. + - btrfs added some stuff. We don't care about this. + - Fuse adds some parallel write support. Will be fine. + - iommufd ioctls added. They fucked up tail padding on some of these ioctls but since I have no idea what this is for, I don't care. + - landlock added fs_truncate. Will be fine. + - HabanaLabs added more things. Still don't care. + - Syscalls + - None added. + - DRM + - Already handled. #2590 +- 6.3 + - Needs work to expose because of the new prctl! + - Detected Changes + - `drm_amdgpu_info_device` added more elements. Will be fine. + - i810 drm removed. + - ivpu drm added. This is their FPGA vision system thing. Packing seems fine. Will fall down generic path and print a warning. + - mga_drm removed + - r128_drm removed + - savage_drm removed + - sis_drm removed + - via_drm removed + - BPF added more stuff again. + - fuse added some stuff. Should be fine. + - prctl PR_{GET,SET}_MDWE added. + - This is dangerous for FEX! It disallows allocating any more memory as `WX`. Which means as soon as this is called, FEX's JIT breaks. + - Can't be undone once enabled. Will likely need to be emulated in syscall handlers. + - rseq adds more fields, should be fine. + - v4l2 adds two new ioctls. Don't care. + - Syscalls + - None added. + - DRM + - amdgpu: Adds some more queries to `IOCTL_AMDGPU_INFO`. FEX doesn't care. + - msm: Default BO_FLAGS options adds `NO_IMPLICIT`. FEX doesn't care. +- 6.4+ (Not released as of 2023-04-09) + - drm/amdgpu: https://patchwork.freedesktop.org/patch/531519/ + - Needs release before full investigation. + +- 6.5 + - cachestat syscall + - new SNDRV ioctls (Needs investigation) + - **Things that FEX doesn't care about** + - Some drm additions that don't change ABI + - bpf additions + - New eventfd flags + - New fcntl `AT_HANDLE_FID` flag + - New FUSE `FUSE_HAS_EXPIRE_ONLY` flag + - new io_uring flags + - new mount flags + - New v4l2 flags + - new VFIO flags + - new asound flags +- 6.6 + - fchmodat syscall + - new `DRM_IOCTL_SYNCOBJ_EVENTFD` ioctl (already implemented) + - New seccomp flags + - `SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP` + - `SECCOMP_IOCTL_NOTIF_SET_FLAGS` + - Will matter when FEX supports user_notif + - **Things that FEX doesn't care about** + - fuse statx thing + - io_uring flags + - iommufd ioctls + - vfio additions +- 6.7 + - New syscalls - already implemented + - map_shadow_stack, futex_wake, futex_wait, futex_requeue + - **Things that FEX doesn't care about** + - btrfs things + - new fuse flags + - New futex2 flags for 8-bit, 16-bit, 32-bit, 64-bit sizes + - io_uring changes + - iommufd again + - landlock changes + - more vfio changes +- 6.8 + - syscall additions + - statmount, listmount, lsm_get_self_attr, lsm_set_self_attr, lsm_list_modules + - more drm ioctl changes + - pvr_drm + - v3d ioctls + - xe_drm + - virtgpu drm flags + - **Things that FEX doesn't care about** + - bpf changes + - soft pages flag thing + - more iommufd things + - kvm changes + - lsm stuff + - mount flags + - netdev changes + - sync_file dead line ioctl + - v4l2 changes + - virtio changes + - asound flag changes +- 6.9 + - **Things that FEX doesn't care about** + - i915 guc change + - More bpf changes + - fs ioctl changes + - fuse changes (fopen passthrough!) + - io_uring changes + - kfd_ioctl changes + - kvm changes + - virtio gpu capset changes + - virtio sound stuff + - auxv + - AT_HWCAP3, AT_HWCAP4 + - Reserved for PowerPC things, x86 won't use it yet. +- 6.10 + - mseal syscall + - panthor_drm + - xe_drm changes + - fcntl notification flags + - Will just get passed through (F_NOTIFY, F_DUPFD_QUERY) + - NTSYNC semaphore ioctl! + - Nothing for FEX to do here, will get passed through + - **Things that FEX doesn't care about** + - i915 changes + - bpf changes + - ethtool changes + - landlock flags + - trace mmap ioctl + - more v4l2 changes + - virtio_net changes + +- 6.11 + - getrandom inside of vdso + - **Things that FEX doesn't care about** + - bpf additions + - btrfs additions + - ethtool things + - procmap_query ioctl - We don't emulate any procfs ioctls + - iommufd things? + - kfd_ioctl additions + - kvm things + - landlock things + - pi things + - mount namespace id ioctl adding + - tcp metrics + - statx atomic write fields +- 6.12 + - some new ioctls + - asound added some at least + - Needs more investigation +- 6.13 + - New drm base ioctl + - New xattr syscalls + - Needs more investigation. \ No newline at end of file diff --git a/results/scraper/fex/2594 b/results/scraper/fex/2594 new file mode 100644 index 000000000..31d90dc18 --- /dev/null +++ b/results/scraper/fex/2594 @@ -0,0 +1,2 @@ +FEX might leak stacks from threads using exit/cancel +Noticed this when looking at fault checking. Need to ensure we're not leaking stacks. \ No newline at end of file diff --git a/results/scraper/fex/26 b/results/scraper/fex/26 new file mode 100644 index 000000000..27639efde --- /dev/null +++ b/results/scraper/fex/26 @@ -0,0 +1,3 @@ +Split OpDispatcher.cpp +The file is ~5100 LoC and should be able to be split up pretty cleanly around tables. +Bit unwieldy to navigate at the current size. \ No newline at end of file diff --git a/results/scraper/fex/261 b/results/scraper/fex/261 new file mode 100644 index 000000000..342bb12ca --- /dev/null +++ b/results/scraper/fex/261 @@ -0,0 +1,2 @@ +Check codegen of llvm/VURAvg for arm64 +The current code likely doesn't use the native `urhadd` opcode, we probably need an intrinsic \ No newline at end of file diff --git a/results/scraper/fex/2631 b/results/scraper/fex/2631 new file mode 100644 index 000000000..875401dde --- /dev/null +++ b/results/scraper/fex/2631 @@ -0,0 +1,2 @@ +Add a unittest that does a dlopen of libFEXCore +Currently this API is completely untested. We should have a CI test that does a baseline implementation check. \ No newline at end of file diff --git a/results/scraper/fex/2637 b/results/scraper/fex/2637 new file mode 100644 index 000000000..d53b81a83 --- /dev/null +++ b/results/scraper/fex/2637 @@ -0,0 +1,2 @@ +ENABLE_MOLD produces broken builds +Linking FEX with `mold` will produce an executable that crashes during startup when attempting to run e.g. `vkcube`. This seems to be a recent regression between now and the start of the `fextl` work, likely related to the `jemalloc` changes. \ No newline at end of file diff --git a/results/scraper/fex/264 b/results/scraper/fex/264 new file mode 100644 index 000000000..f1ee849a8 --- /dev/null +++ b/results/scraper/fex/264 @@ -0,0 +1,6 @@ +`sh/dash -c command` locks up instead of terminating +wait4(...) waits for the job to end, but then returns -1 w/ errno set to NO CHILD. + +repro + +```Bin/ELFLoader -- `which sh` -c ls``` \ No newline at end of file diff --git a/results/scraper/fex/2642 b/results/scraper/fex/2642 new file mode 100644 index 000000000..58526bcb1 --- /dev/null +++ b/results/scraper/fex/2642 @@ -0,0 +1,30 @@ +FEXBash or FEXInterpreter not working +When i try to run FEXBash or FEXInterpreter after installing FEX-Emu on Termux It gives me Segmentation fault error. +What can it be this error? + + + +-I have Installed ubuntu with the comand + +proot-distro install ubuntu + + + + +-Ubuntu login + +proot-distro login --user root ubuntu --shared-tmp + + + + + +-And installed FEX-Emu + +sudo apt update + +sudo apt install software-properties-common + +curl --silent https://raw.githubusercontent.com/FEX-Emu/FEX/main/Scripts/InstallFEX.py --output /tmp/InstallFEX.py && python3 /tmp/InstallFEX.py && rm /tmp/InstallFEX.py + + diff --git a/results/scraper/fex/2644 b/results/scraper/fex/2644 new file mode 100644 index 000000000..5f9532863 --- /dev/null +++ b/results/scraper/fex/2644 @@ -0,0 +1,3 @@ +ARM machine- run x86_64 libraries +Hi! @phire @1ace @skmp @baikaishiuc @philpax +I want to install Qemu on my Arm machine (Ubuntu 22, Linux 4.4, Rock4SE Radxa https://wiki.radxa.com/Rock4/se ) and get access to run libraries so.files in x86_64. Is your FEX a great solution for me? Im new to this. Thanks in advance! :) \ No newline at end of file diff --git a/results/scraper/fex/2645 b/results/scraper/fex/2645 new file mode 100644 index 000000000..9bdac7ee5 --- /dev/null +++ b/results/scraper/fex/2645 @@ -0,0 +1,39 @@ +libFEXCore dlopen/API improvements +Right now even though FEXCore is provided as a shared library, its API is not really something that works if you want to dlopen it. +Static linking and dynamic linking is fine with it though. This comes from FEXCore not ever fully being designed to have dlopen be the path of usage. + +- Experimental branch: https://github.com/Sonicadvance1/FEX/tree/dlopen_improvements +- This provides a little test application that can execute test code + - `LD_LIBRARY_PATH=./External/FEXCore/Source/ ./FEXCore_Test/APITest` + - Need to disable early return on the loader when it fails to find a symbol. + +Lots of thing need to be fixed to work with this. + +- [ ] Provide a loader API to make people's lives easier + - Test branch has this loader in the `FCL::LoadFEXCoreSymbols` function. + - Every symbol then gets exposed under `FCL::` prefix +- [ ] Fully qualify all types used in exported symbols. +- [ ] Remove all uses of class inheritance across the file boundary + - [ ] SignalDelegator + - [ ] SyscallHandler + - [ ] CodeLoader? + - [ ] FEXCore::Config::Layer + - [ ] More? + - This needs to be done because vtable expose across dlopen boundary is a broken mess. + - APITest.cpp has a hack to expose `RegisterFrontendHostSignalHandler` through `FCL` which is a nightmare. + - [ ] Need to provide a helper to expose locally visible `jemalloc` symbols that use `FCL::jemalloc` symbols + - APITest.cpp has a simple wrapper for this. This would need to be a in header that is included in all files that use `fexl::` + - Bit tricky + - [ ] Remove static initializers in FEXCore + - These can cause initialization problems in debug builds when symbols aren't fully loaded yet. + - [ ] Config.cpp + - [ ] More. + - [ ] Need some versioning so that if the loader tries to load a different versioned FEXCore, early exit. + - [ ] Remove duplicated symbol names where the only difference is arguments? + - Might be able to represent these with some thought? Haven't thought hard about it yet. + - [ ] FEXCore::Context::Context::InvalidateGuestCodeRange + - [ ] FEXCore::FileLoading::LoadFile + - [ ] Work towards lessening symbol leakage. If a symbol isn't actually necessary outside of FEXCore, ensure it isn't leaked. + - [ ] Add unit tests that test each aspect of the API individually in as small of chunks as possible + +This is going to be quite a bit of work, so delaying it until absolutely necessary will be nice. \ No newline at end of file diff --git a/results/scraper/fex/2664 b/results/scraper/fex/2664 new file mode 100644 index 000000000..460ebc39d --- /dev/null +++ b/results/scraper/fex/2664 @@ -0,0 +1,4 @@ +AOTIR futexes causing hangs +Steam has a really high chance of hanging due to AOTIR futexes. Theoretically because these are being held while a fork is called? +Really frustrating since this interface is currently broken and unused anyway, so it getting in the way is a pain. +Needs to be fixed because it is likely the cause of hanging in other obscure situations. \ No newline at end of file diff --git a/results/scraper/fex/267 b/results/scraper/fex/267 new file mode 100644 index 000000000..612e3a74f --- /dev/null +++ b/results/scraper/fex/267 @@ -0,0 +1,14 @@ +Libraries we need to Thunk +Libraries we need for performance reasons +- libGL +- libz +- libpng +- libSSL (mbedTLS and OpenSSL?) + + +Libraries we need for compatibility reasons +- steam client libraries? +- libGLX? + + +Add more here \ No newline at end of file diff --git a/results/scraper/fex/2670 b/results/scraper/fex/2670 new file mode 100644 index 000000000..b2b7c0e44 --- /dev/null +++ b/results/scraper/fex/2670 @@ -0,0 +1,3 @@ +Ensure all lock instructions test across cacheline +I noticed the `lock neg` unit test doesn't test across cachelines. +Ensure all of our lock tests have unit tests for across cacheline boundaries. \ No newline at end of file diff --git a/results/scraper/fex/2675 b/results/scraper/fex/2675 new file mode 100644 index 000000000..0feb2423c --- /dev/null +++ b/results/scraper/fex/2675 @@ -0,0 +1,3 @@ +Does this emulator run the Rust Game Dedicated server? +Does this emulator run the Rust Dedicated Game server? +Rust is a multiplayer survival video game \ No newline at end of file diff --git a/results/scraper/fex/2681 b/results/scraper/fex/2681 new file mode 100644 index 000000000..5848d031b --- /dev/null +++ b/results/scraper/fex/2681 @@ -0,0 +1,216 @@ +Sonic Mania movie player very slow block. +Caught while profiling, the Sonic Mania movie player consumes 72% of CPU time in a **SINGLE** block. +This block is mostly just bad because of bad codegen. + + +Block ripped from their deobfuscated executable (32-bit x86). This block jumps to itself. +```asm +movzx edx, byte [esi+ecx] +movzx ecx, byte [esi+edi] +or edx, 0xffff0000 +shl edx, 0x8 +inc esi +or edx, ecx +mov ecx, dword [ebp+0xc {arg5}] +or dword [eax], edx +add eax, 0x4 +cmp esi, ebx +jl 0x5cada0 +``` + +This block is fairly simple, it's combining two bytestreams and a 32-bit stream in to one. Looks like some sort of RGBA combination where one channel is already stored in the destination stream and alpha is forced to 0xFF. +This has some absolutely abysmal codegen. +```asm +(gdb) disas 0x2a10ecfa0,+0x0000013c +Dump of assembler code from 0x2a10ecfa0 to 0x2a10ed0dc: + 0x00000002a10ecfa0: mov w20, w5 + 0x00000002a10ecfa4: mov w21, w10 + 0x00000002a10ecfa8: add w20, w20, w21 + 0x00000002a10ecfac: ldrb w20, [x20] + 0x00000002a10ecfb0: bfxil x6, x20, #0, #32 + 0x00000002a10ecfb4: mov w20, w11 + 0x00000002a10ecfb8: mov w21, w10 + 0x00000002a10ecfbc: add w20, w20, w21 + 0x00000002a10ecfc0: ldrb w20, [x20] + 0x00000002a10ecfc4: bfxil x5, x20, #0, #32 + 0x00000002a10ecfc8: mov w20, w6 + 0x00000002a10ecfcc: orr w20, w20, #0xffff0000 + 0x00000002a10ecfd0: bfxil x6, x20, #0, #32 + 0x00000002a10ecfd4: mov w20, w6 + 0x00000002a10ecfd8: lsl w20, w20, #8 + 0x00000002a10ecfdc: bfxil x6, x20, #0, #32 + 0x00000002a10ecfe0: mov w20, w10 + 0x00000002a10ecfe4: add w20, w20, #0x1 + 0x00000002a10ecfe8: bfxil x10, x20, #0, #32 + 0x00000002a10ecfec: mov w20, w5 + 0x00000002a10ecff0: mov w21, w6 + 0x00000002a10ecff4: orr w20, w21, w20 + 0x00000002a10ecff8: bfxil x6, x20, #0, #32 + 0x00000002a10ecffc: mov w20, w9 + 0x00000002a10ed000: add w20, w20, #0xc + 0x00000002a10ed004: ldr w20, [x20] + 0x00000002a10ed008: bfxil x5, x20, #0, #32 + 0x00000002a10ed00c: mov w20, w6 + 0x00000002a10ed010: mov w21, w4 + 0x00000002a10ed014: ldr w21, [x21] + 0x00000002a10ed018: orr w20, w21, w20 +=> 0x00000002a10ed01c: mov w21, w4 + 0x00000002a10ed020: str w20, [x21] + 0x00000002a10ed024: mov w20, w4 + 0x00000002a10ed028: add w20, w20, #0x4 + 0x00000002a10ed02c: bfxil x4, x20, #0, #32 + 0x00000002a10ed030: mov w20, w7 + 0x00000002a10ed034: mov w21, w10 + 0x00000002a10ed038: sub w22, w21, w20 + 0x00000002a10ed03c: eor w23, w21, w20 + 0x00000002a10ed040: eor w23, w23, w22 + 0x00000002a10ed044: ubfx x23, x23, #4, #1 + 0x00000002a10ed048: strb w23, [x28, #708] + 0x00000002a10ed04c: ubfx x23, x22, #31, #1 + 0x00000002a10ed050: strb w23, [x28, #711] + 0x00000002a10ed054: and x24, x22, #0xff + 0x00000002a10ed058: fmov d0, x24 + 0x00000002a10ed05c: cnt v0.8b, v0.8b + 0x00000002a10ed060: addv b0, v0.8b + 0x00000002a10ed064: umov w24, v0.b[0] + 0x00000002a10ed068: eor x24, x24, #0x1 + 0x00000002a10ed06c: ubfx x24, x24, #0, #1 + 0x00000002a10ed070: strb w24, [x28, #706] + 0x00000002a10ed074: cmp x22, #0x0 + 0x00000002a10ed078: cset x24, eq // eq = none + 0x00000002a10ed07c: strb w24, [x28, #710] + 0x00000002a10ed080: cmp w21, w20 + 0x00000002a10ed084: cset x24, cc // cc = lo, ul, last + 0x00000002a10ed088: strb w24, [x28, #704] + 0x00000002a10ed08c: eor w20, w21, w20 + 0x00000002a10ed090: eor w21, w22, w21 + 0x00000002a10ed094: and w20, w20, w21 + 0x00000002a10ed098: ubfx x20, x20, #31, #1 + 0x00000002a10ed09c: strb w20, [x28, #715] + 0x00000002a10ed0a0: cmp w23, w20 + 0x00000002a10ed0a4: b.ne 0x2a10ecfa0 // b.any + 0x00000002a10ed0a8: b 0x2a10ed0d4 + 0x00000002a10ed0ac: blr x0 + 0x00000002a10ed0b0: ldapurh w0, [x8, #-200] + 0x00000002a10ed0b4: udf #2 + 0x00000002a10ed0b8: .inst 0x005cadc0 ; undefined + 0x00000002a10ed0bc: udf #0 + 0x00000002a10ed0c0: udf #316 + 0x00000002a10ed0c4: udf #0 + 0x00000002a10ed0c8: .inst 0x005cada0 ; undefined + 0x00000002a10ed0cc: udf #0 + 0x00000002a10ed0d0: udf #312 + 0x00000002a10ed0d4: adr x0, 0x2a10ed0d0 + 0x00000002a10ed0d8: str x0, [x28, #184] + ``` + +llvm-mca is quite damning. +```bash +llvm-mca -mcpu=cortex-x1c -mattr=+rcpc-immo mania.txt +Iterations: 100 +Instructions: 6900 +Total Cycles: 5394 +Total uOps: 7100 + +Dispatch Width: 3 +uOps Per Cycle: 1.32 +IPC: 1.28 +Block RThroughput: 23.7 +``` + +And here is an ASM test example that can run in our unit tests to see how much the codegen improves. + +```asm +%ifdef CONFIG +{ + "Mode": "32BIT" +} +%endif + +; Original +; movzx edx, byte [esi+ecx] +; movzx ecx, byte [esi+edi] +; or edx, 0xffff0000 +; shl edx, 0x8 +; inc esi +; or edx, ecx +; mov ecx, dword [ebp+0xc {arg5}] +; or dword [eax], edx +; add eax, 0x4 +; cmp esi, ebx +; jl 0x5cada0 + +mov ebp, 0xe0000000 + +; [ebp + 0xc] contains src1 offset +mov dword [ebp + 0xc], 8 + +; ebx contains loop iteration end offset +lea ebx, .data +add ebx, 1 + +; esi contains the pointer to the data bases +lea esi, .data + +; edi contains src1 offset +mov edi, 0 + +; ecx starts off with src1 offset +mov ecx, dword [ebp + 0xc] + +; eax contains the dword destination and src that it accumulates to +lea eax, .data_dst + +; Break the block here for easier viewing. +jmp .loop_top + +; This loop is the hot loop in Sonic Mania. +.loop_top: +; Load src1 +movzx edx, byte [esi + ecx] +; Load src1 +movzx ecx, byte [esi + edi] + +; set top two channels to 0xFFFF +; Src1 in low bytes - 0xff'ff'00'<src1> +or edx, 0xffff0000 + +; shl edx by 8, shifting off the top 0xff for some reason +; Src1 in low bytes - 0xff'ff'00'<src1> -> 0xff'00'<src1>'00 +shl edx, 0x8 + +; increment byte base +inc esi + +; or in Src1 in to low byte +; 0xff'00'<src1>'<src2> +or edx, ecx + +; Reload src1 offset since it was overwritten +mov ecx, dword [ebp + 0xc] + +; or dword in to eax dest +or dword [eax], edx + +; Increment eax offset +add eax, 0x4 + + +; See if esi matches the end pointer +cmp esi, ebx + +; Rerun loop if the counter isn't at the end yet. +jl .loop_top + +; Exit +hlt + +.data: + +dq 0, 0, 0, 0, 0, 0, 0, 0 + +.data_dst: +dq 0, 0, 0, 0, 0, 0, 0, 0 +``` + +Optimizing the issues in this codegen will significantly improve FEX's codegen all over the codebase. So it will be a significant win everywhere. This is some low hanging fruit in our codegen, theoretically fixing most of this should be easy. \ No newline at end of file diff --git a/results/scraper/fex/2682 b/results/scraper/fex/2682 new file mode 100644 index 000000000..f6bb06982 --- /dev/null +++ b/results/scraper/fex/2682 @@ -0,0 +1,4 @@ +How to install on Termux Proot? +Hi, I was wondering how do I get FEX installed on Termux Proot. I can use box86 but I wanted to try FEX out. + +Thanks.. \ No newline at end of file diff --git a/results/scraper/fex/2684 b/results/scraper/fex/2684 new file mode 100644 index 000000000..dbea66872 --- /dev/null +++ b/results/scraper/fex/2684 @@ -0,0 +1,56 @@ +Support PR_SET_MDWE +Supporting PR_SET_MDWE is complex since FEX needs to allocate RWX JIT sections and this causes an application to no longer be able to execute WX pages. + +This is implemented in kernel 6.3 in commit `b507808ebce23561d4ff8c2aa1fb949fe402bc61` from ARM. This was implemented to work around a BPF filter problem where they couldn't implement RX + BTI mappings for systemd's `MemoryDenyWriteExecute` feature. + +This doesn't prevent allocating memory mirrors with RW + RX permissions. Additionally this flag gets inherited on new threads/processes, so if the application spins a new thread up then FEX will immediately not be able to allocate JIT memory. + +To support this we can do a couple things. +1) Fake it - Just claim it is enabled and not care? +2) Emulate in syscall handler - If enabled, just make sure all mprotect and mmap calls never have `PROT_EXEC | PROT_WRITE`. + - Since this doesn't affect previously mapped things so it works + - An annoyance is FEX needs to track all VMA permissions then (Which we already do for mtrack) and ensure if any are trying to be changed to WX that it gets rejected + - Kind of a pain +3) Implement support for memory mirroring in JIT emitters and just enable. + - Probably the best solution since this doesn't block mirrors having different permissions + - Means we can pass the prctl through to the host + - Need to rewrite the emitter to support this. Given two pointers, one for writing and one for doing PC relative calculations against. + - ICache invalidation operating on executable mapped range + - XByak would need support added as well, which would be a pain. + - Consumes double the VA range for JIT code, should be fine. + - Needs memfd support. + - New JIT region allocation goes from mmap to memfd_create + ftruncate + mmap + mmap + close. + - Code caching also would need to be careful here. +4) mprotect dance + - I have never liked this and don't want it. + - Since we do backpatching this would add even more overhead to that when it should be really quick. + +example: +```cpp +int main() { +#define PR_SET_MDWE 65 +#define PR_MDWE_REFUSE_EXEC_GAIN 1 + prctl(PR_SET_MDWE, PR_MDWE_REFUSE_EXEC_GAIN, 0L, 0L, 0L); + + // Test MDWE by allocating a mirror range. + // One as RX, one as RW. + int memfd = memfd_create("", MFD_CLOEXEC); + ftruncate(memfd, 4096); + // Needs to be MAP_SHARED for the mirror. + void* RW = mmap(nullptr, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, memfd, 0); + void* RX = mmap(nullptr, 4096, PROT_READ | PROT_EXEC, MAP_SHARED, memfd, 0); + close(memfd); + uint64_t Test = 0xc3c3c3c3c3c3c3c3; // Just a bunch of x86-64 ret. + memcpy(RW, &Test, sizeof(Test)); + + uint64_t Result{}; + memcpy(&Result, RX, sizeof(Result)); + printf("Did: 0x%lx == 0x%lx ? %s\n", Test, Result, Test == Result ? "Yes" : "No"); + + using Func = void(*)(); + Func func = (Func)RX; + func(); // Will crash if mirror or protection fails. + + return 0; +} +``` \ No newline at end of file diff --git a/results/scraper/fex/2688 b/results/scraper/fex/2688 new file mode 100644 index 000000000..ea5288847 --- /dev/null +++ b/results/scraper/fex/2688 @@ -0,0 +1,5 @@ +The Witcher 3 slow block + + + +Will populate this with more documentation in the future. \ No newline at end of file diff --git a/results/scraper/fex/2694 b/results/scraper/fex/2694 new file mode 100644 index 000000000..1149c16b7 --- /dev/null +++ b/results/scraper/fex/2694 @@ -0,0 +1,4 @@ +Shadow of the Tomb Raider slow initialization +Running under Proton 7.0, the initial launcher that comes up is burning a bunch of CPU time in our RA for some reason. +Native Linux client doesn't have the issue but this is because the Nixxes launcher is replaced with some Feral CEF one (Which has different issues). + diff --git a/results/scraper/fex/2695 b/results/scraper/fex/2695 new file mode 100644 index 000000000..13d6e8db9 --- /dev/null +++ b/results/scraper/fex/2695 @@ -0,0 +1,43 @@ +Illegal instruction when run Unixbench binary +**What Program** +UnixBench: <https://github.com/kdlucas/byte-unixbench.git>. + +Precompiled binary tarball from [here](https://mega.nz/file/2Ap2yLpa#fhrsi1Weh8jRPx54ccCktZptN-TuQgGaZDxaNACoA_o) + +**Describe the bug** + +I try to run unixbench with FEX-2305 in a kunpeng920(ARMv8.2), but failed with Illegal instruction. +It seems that when run FEX with a host that `SupportsAVX = false` cause this. There may be something wrong with current OpcodeDispatcher. + +**To Reproduce** +Steps to reproduce the behavior: +1. Compile UnixBench in x86 machine, or just download the [precompiled tarball](https://mega.nz/file/2Ap2yLpa#fhrsi1Weh8jRPx54ccCktZptN-TuQgGaZDxaNACoA_o). +2. Set `"EnableAVX": "0"` in Config.json +3. Run `/build/Bin/FEXLoader -- /path/to/byte-unixbench/UnixBench/pgms/dhry2` +4. See error + +**Expected behavior** +print help info normally. +```txt +Usage: ../x86/byte-unixbench/UnixBench/pgms/dhry2 duration +``` + +**Screenshots and Video** +```txt +[ERROR] Invalid or Unknown instruction: VMOVDQA 0x0 +[ERROR] Invalid or Unknown instruction: VMOVUPS 0x0 +[ERROR] Invalid or Unknown instruction: VMOVAPS 0x0 +Illegal instruction +``` + +**System information:** + - OS: Debian bullseye container + - CPU/SoC: [kunpeng920](https://www.hisilicon.com/en/products/Kunpeng/Huawei-Kunpeng/Huawei-Kunpeng-920) + - RootFS used: Self Created Debian bullseye Rootfs + - FEX version: (FEXGetConfig --version) [FEX-2305] + - Thunks Enabled: [No] + +**Additional context** + - Is this an x86 or x86-64 program: [x86-64] + - Does this reproduce on x86-64 host with FEX: [Untested] + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: [Untested and Unrelated] \ No newline at end of file diff --git a/results/scraper/fex/2696 b/results/scraper/fex/2696 new file mode 100644 index 000000000..52b066592 --- /dev/null +++ b/results/scraper/fex/2696 @@ -0,0 +1,4 @@ +Not displaying chinese text +Installed https://aur.archlinux.org/packages/115pc and run `FEXBash /opt/115pc/115`: + + diff --git a/results/scraper/fex/2697 b/results/scraper/fex/2697 new file mode 100644 index 000000000..42df88685 --- /dev/null +++ b/results/scraper/fex/2697 @@ -0,0 +1,13 @@ +wine taskmgr crashing +``` +FEXBash +FEXBash-user@penguin:~> wine taskmgr +0050:err:ole:start_rpcss Failed to start RpcSs service +wine: Unhandled page fault on read access to 00000068 at address 007C5B09 (thread 0024), starting debugger... +Can't attach process 0020: error 5 +Segmentation fault (core dumped) +``` + +fex-emu 2305-1 on archlinux arm + +rootfs: ubuntu 22.04 diff --git a/results/scraper/fex/2698 b/results/scraper/fex/2698 new file mode 100644 index 000000000..579afc301 --- /dev/null +++ b/results/scraper/fex/2698 @@ -0,0 +1,30 @@ +Running ./unbreak_chroot.sh without binfmt +I am running fex inside lxc unprivileged container, which make binfmt register impossible. +I got this when running unbreak script + +``` +./unbreak_chroot.sh +Moving rootfs files back to original location +Moving rootfs folders back to original location +Moving rootfs apt folders back to original location +Changing rootfs permissions on /tmp +Mounting rootfs paths +[sudo] password for user: +Mounting aarch64 paths +mount: /home/user/.fex-emu/RootFS/Ubuntu_22_04/usr/lib/aarch64-linux-gnu: special device /lib/aarch64-linux-gnu does not exist. + dmesg(1) may have more information after failed mount system call. +Starting FEXServer +chmod: cannot access '/tmp/1000-Ubuntu_22_04.chroot': No such file or directory +Chrooting into container +chroot: failed to run command ‘/bin/bash’: Exec format error +Cleaning up chroot +Unmounting aarch64 mounts +umount: /home/user/.fex-emu/RootFS/Ubuntu_22_04/lib/aarch64-linux-gnu: not mounted +Unmounting container mounts +Removing container mount folders +Backing up chroot files +Fixing any potential permission issues +chown: cannot access '/home/user/.fex-emu/RootFS/Ubuntu_22_04/libx32': No such file or directory +``` + +The script relies on binfmt to work. Is it possible to remove this requirement? \ No newline at end of file diff --git a/results/scraper/fex/2707 b/results/scraper/fex/2707 new file mode 100644 index 000000000..831d3300d --- /dev/null +++ b/results/scraper/fex/2707 @@ -0,0 +1,53 @@ +Optimize PF calculation +The PF calculation is very spicy and isn't generating optimal codegen. + +Current codegen: +```asm + 0x00000002a10ed054: and x24, x22, #0xff + 0x00000002a10ed058: fmov d0, x24 + 0x00000002a10ed05c: cnt v0.8b, v0.8b + 0x00000002a10ed060: addv b0, v0.8b + 0x00000002a10ed064: umov w24, v0.b[0] + 0x00000002a10ed068: eor x24, x24, #0x1 + 0x00000002a10ed06c: ubfx x24, x24, #0, #1 + 0x00000002a10ed070: strb w24, [x28, #706] + ``` +What it can be: +```asm + 0x00000002a10ed064: movi v1.8b, #1 + 0x00000002a10ed058: fmov s0, w22 + 0x00000002a10ed05c: cnt v0.8b, v0.8b + 0x00000002a10ed068: bic v0.8b, v1.8b, v0.8b + 0x00000002a10ed070: str b0, [x28, #706] + ``` + +Not a significant reduction in instructions, but removes a FPR->GPR move which is quite an improvement. + +For CPUs with CSSC extension this can be even more optimal but even the upcoming X4/A720/A520 doesn't support them. + +llvm-mca results: +Before: +``` +Iterations: 100 +Instructions: 800 +Total Cycles: 315 +Total uOps: 1000 + +Dispatch Width: 10 +uOps Per Cycle: 3.17 +IPC: 2.54 +Block RThroughput: 3.0 +``` + +After: +``` +Iterations: 100 +Instructions: 500 +Total Cycles: 408 +Total uOps: 600 + +Dispatch Width: 10 +uOps Per Cycle: 1.47 +IPC: 1.23 +Block RThroughput: 3.0 +``` \ No newline at end of file diff --git a/results/scraper/fex/2710 b/results/scraper/fex/2710 new file mode 100644 index 000000000..769b975cc --- /dev/null +++ b/results/scraper/fex/2710 @@ -0,0 +1,544 @@ +[ERROR] Couldn't execute: FEXServer +I recompiled the UnixBench without avx after #2695. + +Then something wired happens. + +```txt +deepin@deepin-PC:~/mcw/FEX/x86/byte-unixbench/UnixBench$ ../../../FEX/build1/Bin/FEXLoad +er ./Run +/home/deepin/.local/share/.fex-emu/RootFS/buster/usr/bin/make all +make[1]: 进入目录“/home/deepin/mcw/FEX/x86/byte-unixbench/UnixBench” +/home/deepin/.local/share/.fex-emu/RootFS/buster/usr/bin/make distr +make[2]: 进入目录“/home/deepin/mcw/FEX/x86/byte-unixbench/UnixBench” +Checking distribution of files +./pgms exists +./src exists +./testdir exists +./tmp exists +./results exists +make[2]: 离开目录“/home/deepin/mcw/FEX/x86/byte-unixbench/UnixBench” +/home/deepin/.local/share/.fex-emu/RootFS/buster/usr/bin/make programs +make[2]: 进入目录“/home/deepin/mcw/FEX/x86/byte-unixbench/UnixBench” +make[2]: 对“programs”无需做任何事。 +make[2]: 离开目录“/home/deepin/mcw/FEX/x86/byte-unixbench/UnixBench” +make[1]: 离开目录“/home/deepin/mcw/FEX/x86/byte-unixbench/UnixBench” +/home/deepin/.local/share/.fex-emu/RootFS/buster/bin/sh: 1: 3dinfo: not found + + # # # # # # # ##### ###### # # #### # # + # # ## # # # # # # # ## # # # # # + # # # # # # ## ##### ##### # # # # ###### + # # # # # # ## # # # # # # # # # + # # # ## # # # # # # # ## # # # # + #### # # # # # ##### ###### # # #### # # + + Version 5.1.3 Based on the Byte Magazine Unix Benchmark + + Multi-CPU version Version 5 revisions by Ian Smith, + Sunnyvale, CA, USA + January 13, 2011 johantheghost at yahoo period com + +------------------------------------------------------------------------------ + Use directories for: + * File I/O tests (named fs***) = /home/deepin/mcw/FEX/x86/byte-unixbench/UnixBench +/tmp + * Results = /home/deepin/mcw/FEX/x86/byte-unixbench/UnixBench +/results +------------------------------------------------------------------------------ + +Wide character in print at ./Run line 1643. +Wide character in printf at ./Run line 1674. + +1 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10 + +1 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10 + +1 x Execl Throughput 1 2 3 + +1 x File Copy 1024 bufsize 2000 maxblocks 1 2 3 + +1 x File Copy 256 bufsize 500 maxblocks 1 2 3 + +1 x File Copy 4096 bufsize 8000 maxblocks 1 2 3 + +1 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10 + +1 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10 + +1 x Process Creation 1 2 3 + +1 x System Call Overhead 1 2 3 4 5 6 7 8 9 10 + +1 x Shell Scripts (1 concurrent) 1 2 3 + +1 x Shell Scripts (8 concurrent) 1 2 3 +Wide character in printf at ./Run line 1574. + +64 x Dhrystone 2 using register variables 1 2 3 4 5 6 7 8 9 10 + +64 x Double-Precision Whetstone 1 2 3 4 5 6 7 8 9 10 + +64 x Execl Throughput 1 2 3 + +64 x File Copy 1024 bufsize 2000 maxblocks 1 2 3 + +64 x File Copy 256 bufsize 500 maxblocks 1 2 3 + +64 x File Copy 4096 bufsize 8000 maxblocks 1 2 3 + +64 x Pipe Throughput 1 2 3 4 5 6 7 8 9 10 + +64 x Pipe-based Context Switching 1 2 3 4 5 6 7 8 9 10 + +64 x Process Creation 1 2 3 + +64 x System Call Overhead 1 2 3 4 5 6 7 8 9 10 + +64 x Shell Scripts (1 concurrent) 1 2 3 + +64 x Shell Scripts (8 concurrent) 1Use of uninitialized value $field in concatenation ( +.) or string at ./Run line 1214, <$childReader> line 405. + +********************************************** +Run: "Shell Scripts (8 concurrent)": [ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't execute: FEXServer +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +rm: 无法删除'grep.24920': 没有那个文件或目录 +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +rm: 无法删除'grep.24922': 没有那个文件或目录 +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +rm: 无法删除'grep.24716': 没有那个文件或目录 +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +rm: 无法删除'grep.24714': 没有那个文件或目录 +rm: 无法删除'grep.24718': 没有那个文件或目录 +rm: 无法删除'grep.24911': 没有那个文件或目录 +rm: 无法删除'grep.24925': 没有那个文件或目录 +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't execute: FEXServer +[ERROR] This means the squashFS rootfs won't be mounted. +[ERROR] Expect errors! +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 61 Connection refused +[ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the p +rocess +[ERROR] FEXServerClient: Failure to setup client +rm: 无法删除'grep.24635': 没有那个文件或目录; aborting +deepin@deepin-PC:~/mcw/FEX/x86/byte-unixbench/UnixBench$ +deepin@deepin-PC:~/mcw/FEX/x86/byte-unixbench/UnixBench$ + +``` + +I just do not know why there are so many error messages about FEXServer, and what the FEXServer does in the whole FEX. \ No newline at end of file diff --git a/results/scraper/fex/2718 b/results/scraper/fex/2718 new file mode 100644 index 000000000..6544cd15b --- /dev/null +++ b/results/scraper/fex/2718 @@ -0,0 +1,4 @@ +Spider-Man: Miles Morales launcher takes a long time to start +This is weirdly anomalous and seems to be hitting some edge case in FEX's emulation. I have noticed a couple of D3D12 games that have this issue but Miles Morales seems to be the easiest to test since it loads in to a launcher instead of directly in to a game. + +The syscall behaviour is very peculiar as well since the CPU thread that is at 100% load is only calling madvise periodically \ No newline at end of file diff --git a/results/scraper/fex/272 b/results/scraper/fex/272 new file mode 100644 index 000000000..72fd151f9 --- /dev/null +++ b/results/scraper/fex/272 @@ -0,0 +1,28 @@ +Curl/OpenSSL failure +``` +./Bin/ELFLoader -T 1 -U -c irint -n 500 -- `which curl` -v -H -GET https://google.com +``` + +This gives a fairly bad output. + +``` +* Trying 172.217.164.110:443... +* TCP_NODELAY set +* Connected to google.com (172.217.164.110) port 443 (#0) +* ALPN, offering h2 +* ALPN, offering http/1.1 +* successfully set certificate verify locations: +* CAfile: /etc/ssl/certs/ca-certificates.crt + CApath: /etc/ssl/certs +* TLSv1.3 (OUT), TLS handshake, Client hello (1): +* TLSv1.3 (IN), TLS handshake, Server hello (2): +* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): +* TLSv1.3 (IN), TLS handshake, Certificate (11): +* TLSv1.3 (OUT), TLS alert, bad certificate (554): +* error:1012606B:elliptic curve routines:EC_POINT_set_affine_coordinates:point is not on curve +* Closing connection 0 +curl: (35) error:1012606B:elliptic curve routines:EC_POINT_set_affine_coordinates:point is not on curve +``` + +This failure point is in openssl. One can build their unit tests and run the `ectest` unit test to see the failure. +Looks like it could be a failure in their BIGNUM implementation but more testing needs to be done. \ No newline at end of file diff --git a/results/scraper/fex/2721 b/results/scraper/fex/2721 new file mode 100644 index 000000000..d183d2818 --- /dev/null +++ b/results/scraper/fex/2721 @@ -0,0 +1,6 @@ +Ultimate chicken horse crashes in mono codegen. +Changing block size to 1 seems to work around the crash for some reason. Might need more aggressive RIP reconstruction. +Will take a look at this soon. + + + diff --git a/results/scraper/fex/2724 b/results/scraper/fex/2724 new file mode 100644 index 000000000..1373490b5 --- /dev/null +++ b/results/scraper/fex/2724 @@ -0,0 +1,21 @@ +Test harness doesn't work on recent glibc due to catchsegv removal` +Trying to run tests on Debian testing + +``` +alyssa@applejack:~/FEX/Build$ ctest -R 'jit_1/Test_VEX/shlx.asm' --output-on-failure +Test project /home/alyssa/FEX/Build + Start 5899: jit_1/Test_VEX/shlx.asm +1/1 Test #5899: jit_1/Test_VEX/shlx.asm ..........***Failed 0.03 sec +Traceback (most recent call last): + File "/home/alyssa/FEX/Scripts/testharness_runner.py", line 58, in <module> + Process = subprocess.Popen(RunnerArgs) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/usr/lib/python3.11/subprocess.py", line 1024, in __init__ + self._execute_child(args, executable, preexec_fn, close_fds, + File "/usr/lib/python3.11/subprocess.py", line 1901, in _execute_child + raise child_exception_type(errno_num, err_msg, err_filename) +FileNotFoundError: [Errno 2] No such file or directory: 'catchsegv' +``` + +See also https://gitlab.gnome.org/GNOME/mutter/-/issues/2120 + diff --git a/results/scraper/fex/2727 b/results/scraper/fex/2727 new file mode 100644 index 000000000..a6f9bf1f9 --- /dev/null +++ b/results/scraper/fex/2727 @@ -0,0 +1,72 @@ +[Game]: Garrys Mod Dedicated Server > Segmentation fault (core dumped) +**What Game** +The game name. +A link to the storefront where to get the game. GOG, Steam, Itch.io, etc +Garrys Mod Dedicated Server +**Describe the bug** +A clear and concise description of what the bug is. +I installing server from linuxgsm like here: https://linuxgsm.com/servers/gmodserver/ +But i getting errora after running, and not like this game, 1 day ago i try to setup rust server, and i get the same error( + +``` +FEXBash-gmodserver@minecraft:~> ./gmodserver install +fetching GitHub core_trap.sh...OK +fetching GitHub _default.cfg...OK +copying _default.cfg...OK +fetching GitHub check_ip.sh...OK +fetching GitHub info_game.sh...OK +fetching GitHub common.cfg...OK +fetching GitHub secrets-common.cfg...OK +fetching GitHub gmodserver.cfg...OK +fetching GitHub secrets-gmodserver.cfg...OK +fetching GitHub linuxgsm.sh...OK +fetching GitHub core_getopt.sh...OK +fetching GitHub command_install.sh...OK +fetching GitHub check.sh...OK +fetching GitHub check_version.sh...OK +fetching GitHub check_tmuxception.sh...OK +fetching GitHub check_permissions.sh...OK +fetching GitHub check_glibc.sh...OK +fetching GitHub info_distro.sh...OK +fetching GitHub check_system_requirements.sh...OK +Segmentation fault (core dumped) +``` + +**To Reproduce** +Steps to reproduce the behavior: +Run this commands: + +``` +FEXBash +wget -O linuxgsm.sh https://linuxgsm.sh && chmod +x linuxgsm.sh && bash linuxgsm.sh gmodserver +./gmodserver install +``` + +**Expected behavior** +And after i getting error: Segmentation fault (core dumped) + +**System information:** +(This is free oracle vds) (Ampere) + + OS: Ubuntu 20.04 focal +Kernel: aarch64 Linux 5.15.0-1037-oracle +Shell: bash 5.0.17 +Disk: 12G / 206G (6%) +CPU: 3.0 GHz Ampere® Altra™ (4x) +RAM: 23988MiB + + - OS: [eg: Ubuntu 21.10] + - CPU/SoC: [eg: Snapdragon 888, Intel Core i8-12900k] + - Video driver version: [eg: OpenGL ES 3.2 Mesa 22.0.0-devel (git-9ff086052a)] + - RootFS used: Installed from FEXBash + - FEX version: FEX-2301 + - Thunks Enabled: [Yes/No]: + +**Additional context** + - Is this an x86 or x86-64 game: [x86/x86-64/Both] + - Does this reproduce on x86-64 host with FEX: [Yes/No/Untested] + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: [Yes/No/Untested] + - Is this a Vulkan game: [Yes/No/Unknown] + - If Yes, What is your Vulkan driver: + +Add any other context about the problem here. diff --git a/results/scraper/fex/2730 b/results/scraper/fex/2730 new file mode 100644 index 000000000..451e1b450 --- /dev/null +++ b/results/scraper/fex/2730 @@ -0,0 +1,8 @@ +FEX page size requirement +## Problem + +I am trying to port FEX in a alpha like architecture, which is 8k pagesize only. + +It seems that FEX requires 4k pagesize. I implement MemAllocator8k and MemAllocator8k32Bit to handle guest memory syscall. + +Currently, the biggest question for me is that what compements of FEXt self , except the guest syscall handler, depends on 4k pagesize. \ No newline at end of file diff --git a/results/scraper/fex/2736 b/results/scraper/fex/2736 new file mode 100644 index 000000000..218eb6a92 --- /dev/null +++ b/results/scraper/fex/2736 @@ -0,0 +1,3 @@ +Library support for C++ +Hi, +I notice that there are only C libraries in FEX Thunklib. I wonder that if FEX is able to support C++ libraries, and whether there are difficulties in supporting C++ libraries. I would be grateful for your reply. \ No newline at end of file diff --git a/results/scraper/fex/2744 b/results/scraper/fex/2744 new file mode 100644 index 000000000..94ae4eb18 --- /dev/null +++ b/results/scraper/fex/2744 @@ -0,0 +1,2 @@ +not finding execution instructions to be very clear +i installed fex installed and extracted the rootfs commands not working im on ubuntu on orange pi 5 is there a gui frontend the wiki just seems to cover setup it gave instructions at the end of the install but then i had a hard drive mounting issue so i had to switch my focus now im lost diff --git a/results/scraper/fex/275 b/results/scraper/fex/275 new file mode 100644 index 000000000..9121eb075 --- /dev/null +++ b/results/scraper/fex/275 @@ -0,0 +1,4 @@ +Generate /proc/cpuid from emulated CPUID +As the emulated CPUID changes, it is hard to remember to update the string backing. +We should generate the string once at startup from the emulated CPUID instead. +Wouldn't be too hard, just a low priority task. \ No newline at end of file diff --git a/results/scraper/fex/2751 b/results/scraper/fex/2751 new file mode 100644 index 000000000..9bab9fbc8 --- /dev/null +++ b/results/scraper/fex/2751 @@ -0,0 +1,24 @@ +fmt getting installed on accident +fmt gets installed on accident with FEX now. That shouldn't happen. Noticed by a user. +``` +-- Up-to-date: /usr/lib/aarch64-linux-gnu/libfmt.a +-- Up-to-date: /usr/include/fmt/args.h +-- Up-to-date: /usr/include/fmt/chrono.h +-- Up-to-date: /usr/include/fmt/color.h +-- Up-to-date: /usr/include/fmt/compile.h +-- Up-to-date: /usr/include/fmt/core.h +-- Up-to-date: /usr/include/fmt/format.h +-- Up-to-date: /usr/include/fmt/format-inl.h +-- Up-to-date: /usr/include/fmt/os.h +-- Up-to-date: /usr/include/fmt/ostream.h +-- Up-to-date: /usr/include/fmt/printf.h +-- Up-to-date: /usr/include/fmt/ranges.h +-- Up-to-date: /usr/include/fmt/std.h +-- Up-to-date: /usr/include/fmt/xchar.h +-- Up-to-date: /usr/lib/aarch64-linux-gnu/cmake/fmt/fmt-config.cmake +-- Up-to-date: /usr/lib/aarch64-linux-gnu/cmake/fmt/fmt-config-version.cmake +-- Up-to-date: /usr/lib/aarch64-linux-gnu/cmake/fmt/fmt-targets.cmake +-- Up-to-date: /usr/lib/aarch64-linux-gnu/cmake/fmt/fmt-targets-release.cmake +-- Up-to-date: /usr/lib/aarch64-linux-gnu/pkgconfig/fmt.pc +``` +Maybe FEX's cmake just needs to set `FMT_INSTALL`? \ No newline at end of file diff --git a/results/scraper/fex/2752 b/results/scraper/fex/2752 new file mode 100644 index 000000000..4dcc0b51e --- /dev/null +++ b/results/scraper/fex/2752 @@ -0,0 +1,4 @@ +java crashing on shutdown on arm64 +Doesn't seem to happen on an x86 host for some reason, but on AArch64 it seems to be the case that it will close on shutdown. + +Causes [Project Zomboid](https://store.steampowered.com/app/108600/Project_Zomboid/) to fail early and seemingly a simple enough test of just running `jre64/bin/java -version` is enough to see it. \ No newline at end of file diff --git a/results/scraper/fex/2753 b/results/scraper/fex/2753 new file mode 100644 index 000000000..966bc419c --- /dev/null +++ b/results/scraper/fex/2753 @@ -0,0 +1,19 @@ +OpenGL thunking not working on xwayland +Thunking that works on xorg fails to run while under xwayland which shouldn't be the case. +Seems to SIGSEGV for some reason. Tested game was [The Binding of Isaac](https://store.steampowered.com/app/250900/The_Binding_of_Isaac_Rebirth/) in some glfw code. Not sure if it is application specific. + +``` +[DEBUG] Thunks: Adding host trampoline for guest function 0x7fffe4814490 via unpacker 0x7fffe4864290 +[DEBUG] Thunks: Finalizing trampoline at 0x7fffe287f240 with host packer 0x7fffe24e7ce0 +[DEBUG] Thunks: Adding host trampoline for guest function 0x7fffe48153c0 via unpacker 0x7fffe48642b0 +[DEBUG] Thunks: Finalizing trampoline at 0x7fffe287f270 with host packer 0x7fffe24e7ca0 +000:<:0013: 24: XInputExtension-Request(131,1): GetExtensionVersion name='XInputExtension' +000:>:0013:32: Reply to GetExtensionVersion: major_version=2 minor_version=4 present=true(0x01) +000:<:0014: 8: XInputExtension-Request(131,47): XIQueryVersion major=2 minor=0 +000:>:0014:32: Reply to XIQueryVersion: major=2 minor=0 +000:<:0015: 28: XKEYBOARD-Request(135,21): PerClientFlags opcode=0x87 opcode2=0x15 unparsed-data=0x00,0x01,0x00,0x00,0x01,0x00,0x00,0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00; +000:>:0015:32: unexpected Reply: data1=0x01 data2=0x00 unparsed-data=0x1f,0x00,0x00,0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00; +000:<:0016: 20: XKEYBOARD-Request(135,23): GetKbdByName opcode=0x87 opcode2=0x17 unparsed-data=0x00,0x01,0x7f,0x00,0x7f,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00; +000:>:0016:32: Reply to GetKbdByName: data1=0x01 data2=0x03 unparsed-data=0x08,0xff,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00; +*** signal 11 +``` \ No newline at end of file diff --git a/results/scraper/fex/2754 b/results/scraper/fex/2754 new file mode 100644 index 000000000..51bb7cdbb --- /dev/null +++ b/results/scraper/fex/2754 @@ -0,0 +1,17 @@ +Canonical PPA build somehow breaking thunks +Behaviour when loading thunks. `Failed to load MakeHostTrampolineForGuestFunction from FEX executable` + +Symbol of `MakeHostTrampolineForGuestFunction` in libX11-host when built from the Canonical PPA builders. +``` +ryanh@ubuntu:/mnt/Work/Work/work/FEXNew/Build_Lenovo$ objdump -D /usr/lib/fex-emu/HostThunks/libX11-host.so | grep "MakeHostTrampolineForGuestFunction" +000000000002ac64 <_ZN7FEXCore34MakeHostTrampolineForGuestFunctionEPvmm>: + 31044: 97ffe708 bl 2ac64 <_ZN7FEXCore34MakeHostTrampolineForGuestFunctionEPvmm> + ``` +Symbol of `MakeHostTrampolineForGuestFunction` in libX11-host when built locally. + ``` +ryanh@ubuntu:/mnt/Work/Work/work/FEXNew/Build_Lenovo$ objdump -D HostLibs_64/libX11-host.so | grep "MakeHostTrampolineForGuestFunction" +000000000002a890 <_ZN7FEXCore34MakeHostTrampolineForGuestFunctionEPvmm>: + 31340: 94001a88 bl 37d60 <_ZN7FEXCore34MakeHostTrampolineForGuestFunctionEPvmm@plt> + ``` + +Somehow this weak symbol is getting converted from a plt to a direct branch with the canonical PPA, breaking FEX's thunks in the process. `-Bsymbolic-functions` seems to be the only additional compile option that stands out but when manually adding it I couldn't reproduce this issue. Do we need to convert it to always be an undefined symbol rather than a weak symbol so this can never occur? \ No newline at end of file diff --git a/results/scraper/fex/276 b/results/scraper/fex/276 new file mode 100644 index 000000000..9b24ccda2 --- /dev/null +++ b/results/scraper/fex/276 @@ -0,0 +1,3 @@ +Strip out ARM Simulator +We all have relevant ARM64 devices to test on now. Remove this bit of cruft, we no longer have a reason to use it. +It's also blocking more work to improve RA. \ No newline at end of file diff --git a/results/scraper/fex/2767 b/results/scraper/fex/2767 new file mode 100644 index 000000000..473e62d00 --- /dev/null +++ b/results/scraper/fex/2767 @@ -0,0 +1,2 @@ +JP is broken +We store the popcount of the bottom byte in the parity flag, even though only the bottom bit matters. But JP will check the flag by comparing against zero... meaning JP will branch any time the input is nonzero, ignoring parity. \ No newline at end of file diff --git a/results/scraper/fex/2780 b/results/scraper/fex/2780 new file mode 100644 index 000000000..83b01995c --- /dev/null +++ b/results/scraper/fex/2780 @@ -0,0 +1,35 @@ +SRA inserts arbitrary move for some reason? +Simple unit test to see the issue. +```asm +%ifdef CONFIG +{ + "RegData": { + "RAX": "0x4" + } +} +%endif + +mov rax, 1 +mov rbx, 1 +shld rax, rbx, 2 + +hlt +``` + +Resulting IR for the shld instruction. +``` + (%3 i0) BeginBlock %2(Invalid) + %4(GPRFixed3) i64 = LoadRegister #0x0, #0x20, GPR, GPRFixed, u8:Tmp:Size + %5(GPR0) i64 = LoadRegister #0x0, #0x8, GPR, GPRFixed, u8:Tmp:Size + %6(GPRFixed0) i64 = Extr %5(GPR0) i64, %4(GPRFixed3) i64, #0x3e + ... +``` + +As seen, the first source to the `Extr` IR op doesn't get assigned to static register allocation for some reason. +This results in a redundant move when the Arm64 JIT emits code. +```asm +0x0000ffff840800a4 aa0403f4 mov x20, x4 +0x0000ffff840800a8 93c7fa84 extr x4, x20, x7, #62 +``` + +Unknown how many places in the JIT this causes arbitrary moves. Noticed while writing #2779 \ No newline at end of file diff --git a/results/scraper/fex/2802 b/results/scraper/fex/2802 new file mode 100644 index 000000000..8bee7f580 --- /dev/null +++ b/results/scraper/fex/2802 @@ -0,0 +1,62 @@ +CMPXCHG16B no longer produces optimal code +This /used/ to produce optimal code before SRA was introduced, and maybe before some enums were rearranged. + +Test case: +```asm +%ifdef CONFIG +{ +} +%endif + +mov rsp, 0xe0001000 +cmpxchg16b [rsp] + +hlt +``` + +ASM for cmpxchg16b +```asm +0x00007f3ec2e80060 10ffffe0 adr x0, #-0x4 (addr 0x7f3ec2e8005c) +0x00007f3ec2e80064 f9005f80 str x0, [x28, #184] +; Moving SRA registers RDX:RAX in to element pair (expected). +0x00007f3ec2e80068 aa0403f4 mov x20, x4 +0x00007f3ec2e8006c aa0603f5 mov x21, x6 +; Moving SRA registers RCX:RBX in to element pair (Desired). +0x00007f3ec2e80070 aa0703f6 mov x22, x7 +0x00007f3ec2e80074 aa0503f7 mov x23, x5 +; Moving *expected* in to temporaries. Because the ARM instruction overwrites these . (In IR Op) +; We don't detect when Dst == Expected, nor have constraints to enforce it. +0x00007f3ec2e80078 aa1403e2 mov x2, x20 +0x00007f3ec2e8007c aa1503e3 mov x3, x21 +; Rock the caspal +0x00007f3ec2e80080 4862fd16 caspal x2, x3, x22, x23, [x8] +; Move the result back in to destination (In IR Op) +0x00007f3ec2e80084 aa0203f4 mov x20, x2 +0x00007f3ec2e80088 aa0303f5 mov x21, x3 +; ExtractElementPair(0) - Ugh RA. +0x00007f3ec2e8008c aa1403f6 mov x22, x20 +; ExtractElementPair(1) - Ugh RA. +0x00007f3ec2e80090 aa1503f4 mov x20, x21 +; Calculate if Memory == Expected +0x00007f3ec2e80094 ca0402d5 eor x21, x22, x4 +0x00007f3ec2e80098 ca060297 eor x23, x20, x6 +0x00007f3ec2e8009c aa1702b5 orr x21, x21, x23 +0x00007f3ec2e800a0 f10002bf cmp x21, #0x0 (0) +0x00007f3ec2e800a4 9a9f17f7 cset x23, eq +; Set ZF to result +0x00007f3ec2e800a8 390b1b97 strb w23, [x28, #710] +; Skip block if ZF was expected. +0x00007f3ec2e800ac b4000075 cbz x21, #+0xc (addr 0x7f3ec2e800b8) +; If ZF wasn't expected, RDX:RAX gets set to the memory that was loaded. +; Need to be careful here, CMPXCHG8B must /not/ clear the upper bits if memory was expected. +; Could generate more optimal code if we know the upper bits are already zero, operating in 32-bit mode, or 16B since upper bits will always be set +0x00007f3ec2e800b0 aa1603e4 mov x4, x22 +0x00007f3ec2e800b4 aa1403e6 mov x6, x20 +; Tail block. +0x00007f3ec2e800b8 58000040 ldr x0, pc+8 (addr 0x7f3ec2e800c0) +0x00007f3ec2e800bc d63f0000 blr x0 +0x00007f3ec2e800c0 d8d7f128 prfm plil1keep, pc-328156 (addr 0x7f3ec2e2fee4) +0x00007f3ec2e800c4 00007f3e udf #0x7f3e +0x00007f3ec2e800c8 0001000a unallocated (Unallocated) +0x00007f3ec2e800cc 00000000 udf #0x0 +``` \ No newline at end of file diff --git a/results/scraper/fex/2810 b/results/scraper/fex/2810 new file mode 100644 index 000000000..a915b8d88 --- /dev/null +++ b/results/scraper/fex/2810 @@ -0,0 +1,3 @@ +Alyssa's notes +- [ ] RA should turn uninlined zeroes into xzr +- [ ] umul flag setting could do `cmp xzr, x0, lsr #32` and do a `ne` condition. \ No newline at end of file diff --git a/results/scraper/fex/2818 b/results/scraper/fex/2818 new file mode 100644 index 000000000..04745f6db --- /dev/null +++ b/results/scraper/fex/2818 @@ -0,0 +1,55 @@ +PSAD has unnecessary moves +Can be seen in `OpSize/66_F6.asm` + +```asm +adr x0, #-0x4 (addr 0x7fffe2080844) +str x0, [x28, #184] +ldr q4, [x6, #240] +uabdl v5.8h, v24.8b, v4.8b +uabdl2 v4.8h, v24.16b, v4.16b +addv h5, v5.8h +addv h4, v4.8h +mov v0.16b, v5.16b +mov v0.d[1], v4.d[0] +mov v24.16b, v0.16b +ldr x0, pc+8 (addr 0x7fffe2080878) +blr x0 +``` + +The three moves at the end are unnecessary and can be implemented as follows. +```asm +adr x0, #-0x4 (addr 0x7fffe2080844) +str x0, [x28, #184] +ldr q4, [x6, #240] +uabdl v5.8h, v24.8b, v4.8b +uabdl2 v4.8h, v24.16b, v4.16b +addv v24.16b, v5.8h +addv h4, v4.8h +mov v24.d[1], v4.d[0] +ldr x0, pc+8 (addr 0x7fffe2080878) +blr x0 +``` + +IR: +``` + (%2) CodeBlock %3, %17 + (%3 i0) BeginBlock %2(Invalid) + (%4 i0) GuestOpcode #0x0 + %5(FPRFixed8) i128 = LoadRegister #0x0, #0x140, FPR, FPRFixed, u8:Tmp:Size + %6(GPRFixed2) i64 = LoadRegister #0x0, #0x18, GPR, GPRFixed, u8:Tmp:Size + (%7 i64) InlineConstant #0xf0 + %8(FPR0) i128 = LoadMem FPR, u8:Tmp:Size, %6(GPRFixed2) i64, %7(Invalid), #0x10, SXTX, #0x1 + %9(FPR1) i16v8 = VUABDL u8:Tmp:RegisterSize, u8:Tmp:ElementSize, %5(FPRFixed8) i128, %8(FPR0) i128 + %10(FPR0) i16v8 = VUABDL2 u8:Tmp:RegisterSize, u8:Tmp:ElementSize, %5(FPRFixed8) i128, %8(FPR0) i128 + %11(FPR1) i16v8 = VAddV u8:Tmp:RegisterSize, u8:Tmp:ElementSize, %9(FPR1) i16v8 + %12(FPR0) i16v8 = VAddV u8:Tmp:RegisterSize, u8:Tmp:ElementSize, %10(FPR0) i16v8 + %13(FPRFixed8) i64v2 = VInsElement u8:Tmp:RegisterSize, u8:Tmp:ElementSize, #0x1, #0x0, %11(FPR1) i16v8, %12(FPR0) i16v8 + (%14 i128) StoreRegister %13(FPRFixed8) i64v2, #0x0, #0x140, FPR, FPRFixed, u8:Tmp:Size + (%15 i64) InlineEntrypointOffset #0x9, u8:Tmp:RegisterSize + (%16 i64) ExitFunction %15(Invalid) + (%17 i0) EndBlock %2(Invalid) +``` + +This is because the first `VAddV` doesn't understand it can get stored in to the vector. Which means the `VInsertElement` does a mov+mov+mov. + +Care must be taken as usual that if the destination is to memory, that we don't turn the store in to multiple memory stores. \ No newline at end of file diff --git a/results/scraper/fex/2836 b/results/scraper/fex/2836 new file mode 100644 index 000000000..b509f528a --- /dev/null +++ b/results/scraper/fex/2836 @@ -0,0 +1,21 @@ +Missing GPR aliases in ARMEmitter +- [x] tst +- [x] bfc +- [x] bfxil +- [x] cinc +- [x] cinv +- [x] csetm +- [x] stadd{a,al,l,}{b,h,} -mishmash of these +- [x] strclr{a,al,l}{b,h,} -mishmash of these +- [x] streor{a,al,l}{b,h,} -mishmash of these +- [x] strset{a,al,l}{b,h,} -mishmash of these +- [x] stsmax{a,al,l}{b,h,} +- [x] stsmin{a,al,l}{b,h,} +- [x] stumax{a,al,l}{b,h,} +- [x] stumin{a,al,l}{b,h,} +- [x] ngc +- [x] ngcs +- [x] sbfiz +- [x] ubfiz + +Seems to be all of the missing GPR aliases from a quick scan of the ARM ARM. \ No newline at end of file diff --git a/results/scraper/fex/2840 b/results/scraper/fex/2840 new file mode 100644 index 000000000..8774a51dd --- /dev/null +++ b/results/scraper/fex/2840 @@ -0,0 +1,19 @@ +Wine WoW64 not working on FEX +I'm trying to improve the performance of 32-bit programs by using FEX with Wine WoW64 (as it's known that FEX performs better for translating 64-bit compared to 32-bit). However, Wine WoW64 doesn't work properly under FEX. + +This is the output of wine: + +``` +root@localhost:~# winewow 7z2301.exe +002c:err:wineboot:process_run_key Error running cmd L"C:\\windows\\system32\\winemenubuilder.exe -a -r" (2). +0078:err:wineusb:usb_init Failed to initialize libusb: Other error +0074:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 +007c:err:hid:sdl_bus_init could not init SDL: Could not initialize UDEV +0074:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 +0074:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 +0074:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 +0024:err:environ:init_peb starting L"Z:\\root\\7z2301.exe" in experimental wow64 mode +0024:err:seh:signal_init_process failed to allocate %fs selector +``` + +How to resolve this? \ No newline at end of file diff --git a/results/scraper/fex/2841 b/results/scraper/fex/2841 new file mode 100644 index 000000000..f4dd50228 --- /dev/null +++ b/results/scraper/fex/2841 @@ -0,0 +1,20 @@ +Denuvo needs inline self-modifying code support +Currently it crashes because of an invalid instruction. +The instruction stream (From Hatsune Miku Project DIVA Mega Mix+) starts as follows. +```asm +1569854b0 812d000000001896… sub dword [rel data_1569854ba], 0x1b519618 {0xa20f9090} // Modifies the next instruction +1569854ba a826 test al, 0x26 // Instruction modified +1569854bc 61 ?? +``` + +The initial sub instruction in this block is modifying the code just after the instruction. Which turns it in to: +```asm +0x00000000 1 90 nop +0x00000001 1 90 nop +0x00000002 2 0fa2 cpuid +0x00000004 10 8105f2ffffff1896511b add dword [rip - 0xe], 0x1b519618 +0x0000000e 1 c3 ret +``` + +The final add there modifying the code back to what it was before. +FEX need to have a generic (and fast) solution towards detecting something like this if we want any Denuvo Anti-Tamper games to work. \ No newline at end of file diff --git a/results/scraper/fex/2849 b/results/scraper/fex/2849 new file mode 100644 index 000000000..375c2c37e --- /dev/null +++ b/results/scraper/fex/2849 @@ -0,0 +1,2 @@ +man page install doesn't respect install prefix +cmake files need to be adjusted so that `/usr/share/man/man1/FEX.1.gz` isn't a hardcoded path, enabling non-system installs \ No newline at end of file diff --git a/results/scraper/fex/2853 b/results/scraper/fex/2853 new file mode 100644 index 000000000..ea78c0c4a --- /dev/null +++ b/results/scraper/fex/2853 @@ -0,0 +1,37 @@ +[Game]: ARK just not start, without any error +**What Game** +ARK Survival Evolved Dedicated Server +https://store.steampowered.com/app/346110/ARK_Survival_Evolved/ + +**Describe the bug** +When I try to start the game, they execute the binary without problems, but, stops there. Does not give me more info after that. + +**To Reproduce** +Steps to reproduce the behavior: +1. Go to '/ARK/ShooterGame/Binaries/Linux/' +2. Executes 'ShooterGameServer' +3. Stuck there + +**Expected behavior** +When I start, at least, give me a error to figure what I need to do. + +**Screenshots and Video** + +_Using FEXBash_ + + +_Running for a long time_ + + +**System information:** + - OS: Ubuntu Server 22.04 LTS + - CPU/SoC: ARM Neoverse-N1 + - RootFS used: Default from installation + - FEX version: FEX-2307 + - Thunks Enabled: No + +**Additional context** + - Is this an x86 or x86-64 game: x64 only + - Does this reproduce on x86-64 host with FEX: Untested + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: No \ No newline at end of file diff --git a/results/scraper/fex/2906 b/results/scraper/fex/2906 new file mode 100644 index 000000000..4d19afab8 --- /dev/null +++ b/results/scraper/fex/2906 @@ -0,0 +1,12 @@ +List of games that need RDTSC scaling +It has been reported that some games will use RDTSC, making the assumption that it ticks at the rate of the nominal CPU frequency. Ideally the games would measure the RDTSC tick rate or on modern Intel platforms read the CPUID status bits for this. + +We can potentially scale the RDTSC to a ratio of the "nominal" cpu frequency. Once ARMv8.6/9.1 chips come with a 1Ghz frequency, we can easily do a 1.5x/2x/3x scale rather than the MASSIVE scale required for today's chips of 19.2Mhz. + +We need to keep a list of games that need this workaround since I have noticed a few that it seems to have issues. + +**Seemingly confirmed games** +- Horizon Zero Dawn + +**Potential games with this issue** +- Warhammer 40k: Gladius - Relics of war (Or maybe one of the other Warhammer games?) \ No newline at end of file diff --git a/results/scraper/fex/2995 b/results/scraper/fex/2995 new file mode 100644 index 000000000..17cb654f8 --- /dev/null +++ b/results/scraper/fex/2995 @@ -0,0 +1,44 @@ +cvttpd2dq is probably broken +According to InstCountCI, +``` +cvttpd2dq xmm0, xmm1 +``` +Translates to: +``` +fcvtn v4.2s, v17.2d +fcvtzs v16.4s, v4.4s +``` + +`fcvtn` converts from a double to a float, which is a lossy operation. For example, the double 100000001.0 turns into the float 100000000.0f. (These are safely within the integer range, so the result will be the integer 100000000 instead of 100000001.) + +I suspect the tests are inadequate, mostly testing small, positive numbers: https://github.com/FEX-Emu/FEX/blob/c5f358b47adfc7afe00f7aeeddbd8fb28b5f601c/unittests/ASM/VEX/vcvttpd2dq.asm#L47-L55 + +As well as a value that is too small to see the problem (0x4142434445464748 -> 2393736.541207228), and a value that is too large (0x5152535455565758 -> 5.562560877255032e+83) (and -1.0 and -2.0): + +https://github.com/FEX-Emu/FEX/blob/c5f358b47adfc7afe00f7aeeddbd8fb28b5f601c/unittests/ASM/OpSize/66_E6.asm#L25-L28 + +I'd recommend testing with positive and negative powers of two (2^0 through 2^33 for a 32-bit operation like this) ± {1, 0.5, 0.25, 0.75} for tests, and adding zero, positive and negative infinity, and NaN: + +* 2**30±1 covers loss of precision +* 2**n±0.5 ensures that numbers half-way between integers are rounding correctly +* 2**n±0.25/0.75 test for rounding up/down/nearest. +* Going up to 2**33 tests the out-of-range result. +* Including negative numbers tests negative-out-of-range, and negative-rounding (e.g. rounding towards zero vs towards negative-infinity are indistinguishable when testing only positive numbers). +* Infinity, NaN and zero are common floating point special cases. + +Python code to generate these: +```python +import struct + +l = set() +for i in range(34): + for j in [0, 1, 0.5, 0.25, 0.75]: + l.add(float(2**i+j)) + l.add(float(2**i-j)) + +for i in list(l): + l.add(-i) + +for i in [float('-inf')] + sorted(l) + [float('inf'), float('nan')]: + print('dq 0x%016X ; %r' % (struct.unpack('<Q', struct.pack('<d',i))[0], i)) +``` \ No newline at end of file diff --git a/results/scraper/fex/2996 b/results/scraper/fex/2996 new file mode 100644 index 000000000..6a38afcc3 --- /dev/null +++ b/results/scraper/fex/2996 @@ -0,0 +1,119 @@ +State of externals / dependencies (Updating / Upstreaming / Unforking) +**Take anything below with a grain of salt; it's only based on a quick skim over the externals.** + +--- + +Background: I wrote this list a couple of days ago after briefly discussing fex on the Asahi Linux Fedora matrix channel. +Basically for Asahi Fedora it would be beneficial if more of the dependencies could come from the system. +So I went and checked the externals and wrote down some thoughts. +Because I don't have a lot of time right now I'm posting it in the current state, so it doesn't go to waste on my local disk. +However, it's not polished and might be incorrect. + +My hope with this issue is: +- Someone updates the libs which come from upstream. +- Discussion / feedback which libs must remain bundled and why (which could be an argument for packagers). +- Discussion how system libs could be used (e.g. by moving the custom CMake files out of forks or merging them upstream). +- Split this meta-issue into smaller, more manageable, issues (e.g. "Update to catch 3.x") which can be closed once a task is finished. + +--- + +For packaging FEX, it might be beneficial to use system libraries. + +I'm listing the state of the externals here: + + + +## [Catch2 @ c4e3767](https://github.com/catchorg/Catch2/tree/c4e3767e265808590986d5db6ca1b5532a7f3d13) + +This is v2.13.7 +Newest v2: v2.13.10 +Newest v3: v3.4.0 + +## [Vulkan-Headers @ 98f440c](https://github.com/KhronosGroup/Vulkan-Headers/tree/98f440ce6868c94f5ec6e198cc1adda4760e8849) + +This is v1.3.231 +Newest: v1.3.261 + +## [fmt @ a0b8a92](https://github.com/fmtlib/fmt/tree/a0b8a92e3d1532361c2f7feb63babc5c18d00ef2) + +This is 10.0.0 +Newest: 10.1.0 + +## [imgui @ 4c986ec](https://github.com/Sonicadvance1/imgui/tree/4c986ecb8d2807087fd8e34894d1e7a138bc2f1d) + +This is a fork starting at 0bdc1453433ab0bb4d889c72ef9b0353ba3998aa (August 2019) + +Changes: +- Don't autodetect OpenGL ES with custom loader + - ? +- Disable glPolygonMode with ES. We aren't using it anyway. + - Not sure why this commit exists +- Fixes KP enter on imgui SDL impl + - This feels like something for upstream +- Add CMake file + - Upstream rejects this / has trouble finding a working solution +- Add imgui addons + - No idea where all of this comes from, but potentially problematic for switching to upstream +- Add a mapping of keypad enter to map to regular enter key. + - This feels like something for upstream + +## [jemalloc @ 16f8061](https://github.com/FEX-Emu/jemalloc/tree/16f80619558c44c917695228e00c1a7ec1b2b752) & [jemalloc_glibc @ 888181c](https://github.com/FEX-Emu/jemalloc/tree/888181c5f7072ab1bd7aa7aca6d9f85816a95c43) + +Forked from 5.3.0. +This has various changes, and likely needs to remain a fork + +## [json-maker @ 8ecb8ec](https://github.com/Sonicadvance1/json-maker/tree/8ecb8ecc348bf88c592fac808c03efb342f69e0a) + +Forked from 66cb2b7a5155417898463152e247eb8b2ae6fff8 (November 2018) + +Changes: +- Add CMake file + - Upstream has a CMake file now, too + +This should probably be migrated to the upstream version. + +## [robin-map @ f1ab690](https://github.com/FEX-Emu/robin-map/tree/f1ab6900466891af11e3c264c63acf1dd9c3532c) + +Forked from v1.2.1 + +Changes: +- Make empty bucket be a per-map object. Needed to fix allocation problems + - This might be hard or impossible to fix (and also suggest this might be a problem for other libraries) + +## [tiny-json @ 9d09127](https://github.com/Sonicadvance1/tiny-json/tree/9d09127f87ea6a128fb17d1ffd0b444517343f1c) + +Forked from 58200fff5cc0df857f9aca7e53fbc4a8db88ef19 (March 2019) + +Changes: +- Add CMake file + - can probably be done upstream; same author as json-maker, and that has gotten a CMake file upstream + + +## [vixl @ debc345](https://github.com/FEX-Emu/vixl/tree/debc3456835003b0e577f905b54bfd5addbf14db) + +Changes: +- Smaller bugfixes and CMake file + +At least one of the bugfixes has been upstreamed, at least one other bugfix is no longer needed due to a different implementation. + +## [xbyak @ 5f8c048](https://github.com/FEX-Emu/xbyak/tree/5f8c0488bab7a5e1c8cee831c3b6a5a884e10df8) + +This is v6.68 + +Changes: +- Allow custom allocators for xbyak +- Support cpuid CLWB +- Adds back missing SSE4a check +- Disables xbyak db code size checking +- Adds new setNewBuffer function + +Except for the last one, these feel upstreamable. +The last one sounds dangerous-by-design, so this might not be possible? + +## [xxhash @ ba7375d](https://github.com/FEX-Emu/xxHash/tree/ba7375d54fbbf7bfd9519b465a146e9a8bf0240f) + +Forked from 35b0373c697b5f160d3db26b1cbb45a0d5ba788c (November 2019) + +Changes: +- Adds CMakeLists file + - Upstream already had this in /cmake_unofficial/ \ No newline at end of file diff --git a/results/scraper/fex/3011 b/results/scraper/fex/3011 new file mode 100644 index 000000000..12ff3c2a4 --- /dev/null +++ b/results/scraper/fex/3011 @@ -0,0 +1,5 @@ +Okami HD has some case of spiky polygon syndrome +This is more easily visible in movement but can be reproduced by opening and close the menu a few times as seen in the picture. (The big triangle isn't supposed to look like that) +It happens frequently to vertices while the game is running. I don't remember seeing this before so it is likely a regression. + + \ No newline at end of file diff --git a/results/scraper/fex/3019 b/results/scraper/fex/3019 new file mode 100644 index 000000000..8ebdab595 --- /dev/null +++ b/results/scraper/fex/3019 @@ -0,0 +1,6 @@ +Yea, I noticed that but I'm leaving it alone for now since I don't want codegen to change with these right now. Tackling one problem at a time. + Yea, I noticed that but I'm leaving it alone for now since I don't want codegen to change with these right now. Tackling one problem at a time. +Changing it to 32-bit only operation causes InstCountCI churn half-way through this process but we can make sure to come back to this once implicit size is gone. + +_Originally posted by @Sonicadvance1 in https://github.com/FEX-Emu/FEX/pull/3017#discussion_r1307345959_ + \ No newline at end of file diff --git a/results/scraper/fex/3032 b/results/scraper/fex/3032 new file mode 100644 index 000000000..f99786be2 --- /dev/null +++ b/results/scraper/fex/3032 @@ -0,0 +1,7 @@ +Drracket crash +Trying to open drracket (Racket IDE) fails with +``` +Error: error reading from ~a +("petite") +Aborted (core dumped) +``` \ No newline at end of file diff --git a/results/scraper/fex/3045 b/results/scraper/fex/3045 new file mode 100644 index 000000000..a72698d53 --- /dev/null +++ b/results/scraper/fex/3045 @@ -0,0 +1,5 @@ +Optimize NEG flag calculation + Note to self: fix const prop to further improve this code? + +_Originally posted by @alyssarosenzweig in https://github.com/FEX-Emu/FEX/pull/3035#discussion_r1311554470_ + \ No newline at end of file diff --git a/results/scraper/fex/3060 b/results/scraper/fex/3060 new file mode 100644 index 000000000..a4c08a2dd --- /dev/null +++ b/results/scraper/fex/3060 @@ -0,0 +1 @@ +DEC pointlessly inverts CF diff --git a/results/scraper/fex/3086 b/results/scraper/fex/3086 new file mode 100644 index 000000000..fe225f2b9 --- /dev/null +++ b/results/scraper/fex/3086 @@ -0,0 +1,11 @@ +SPDX in FEX's sources +FEX needs to slap SPDX in to all of its sources to make mixed license files less of an issue. + +This should just be putting `// SPDX-License-Identifier: MIT` on the first line of every FEX file. +Probably want to make sure it doesn't conflict with with the `Scripts/doc_outline_generator.py` thing that is run every release. + +Let's start a discussion about doing this to see if anyone has any comments about this. +- Should it just be `// SPDX-License-Identifier: MIT` ? +- Any concerns? + +I personally have never used SPDX so I don't know if there are any particular problems that could crop up. \ No newline at end of file diff --git a/results/scraper/fex/310 b/results/scraper/fex/310 new file mode 100644 index 000000000..27e7f63a0 --- /dev/null +++ b/results/scraper/fex/310 @@ -0,0 +1,4 @@ +Make a rootfs that distributes to runners +- Ubuntu and/or Arch +- Installs a bunch of libraries we want to thunk +- Second step installs fex things in to it. \ No newline at end of file diff --git a/results/scraper/fex/311 b/results/scraper/fex/311 new file mode 100644 index 000000000..b62de0769 --- /dev/null +++ b/results/scraper/fex/311 @@ -0,0 +1,7 @@ +Unaligned atomic memory ops support +Currently x86 instructions translated to the atomic IR ops aren't expecting an alignment. +Compilers will go out of their way to avoid these unaligned atomics on the x86 side due to the "big ring lock" but they can still be done. +ARMv8.4-LSE resolves this issue mostly where it relaxes the atomic alignment problem. + +But we still need to work with unaligned atomics on older ARMv8 versions, and doesn't resolve the problem of an unaligned atomic crossing a cacheline (x86 works in this instance). +Will need a backpatch + fallback handling, or if it happens non-frequently, handle it in the signal handler and dispatch a threaded recompiled replacement. \ No newline at end of file diff --git a/results/scraper/fex/3117 b/results/scraper/fex/3117 new file mode 100644 index 000000000..7240241ba --- /dev/null +++ b/results/scraper/fex/3117 @@ -0,0 +1,9 @@ +Ideas to improve PF calculation +There is a lot of room for improvement here but most of it requires doing more work than I'm up for this morning. + +- [x] setp should do ands to avoid the cmp + +- [ ] lahf can use orn+ornlshl to replace and+eor+orlshl, details left to reader. + +_Originally posted by @alyssarosenzweig in https://github.com/FEX-Emu/FEX/issues/3116#issuecomment-1723661878_ + \ No newline at end of file diff --git a/results/scraper/fex/312 b/results/scraper/fex/312 new file mode 100644 index 000000000..132f68e46 --- /dev/null +++ b/results/scraper/fex/312 @@ -0,0 +1,4 @@ +Buildbots need an assert enabled build +Build a release build with asserts enabled. +This will allow us to keep most of the speed but have asserts fire still, which are currently missed. +Also ensure the IR Validation passes are enabled. \ No newline at end of file diff --git a/results/scraper/fex/3127 b/results/scraper/fex/3127 new file mode 100644 index 000000000..bedbf3793 --- /dev/null +++ b/results/scraper/fex/3127 @@ -0,0 +1,10 @@ +Newest vkd3d-proton needs updated Vulkan thunks +Hits new functions that we don't expose. +``` +vkGetDeviceProcAddr: Unknown Vulkan function at address 0x7ffd94fe0ba4: vkGetDescriptorEXT +vkGetDeviceProcAddr: Unknown Vulkan function at address 0x7ffd94fbfe34: vkCmdBindDescriptorBuffersEXT +vkGetDeviceProcAddr: Unknown Vulkan function at address 0x7ffd94fbff88: vkCmdBindDescriptorBufferEmbeddedSamplersEXT +vkGetDeviceProcAddr: Unknown Vulkan function at address 0x7ffd94fbfee0: vkCmdSetDescriptorBufferOffsetsEXT +vkGetDeviceProcAddr: Unknown Vulkan function at address 0x7ffd94fdfa4c: vkGetDescriptorSetLayoutSizeEXT +vkGetDeviceProcAddr: Unknown Vulkan function at address 0x7ffd94fdfa58: vkGetDescriptorSetLayoutBindingOffsetEXT +``` \ No newline at end of file diff --git a/results/scraper/fex/313 b/results/scraper/fex/313 new file mode 100644 index 000000000..006bc5ed9 --- /dev/null +++ b/results/scraper/fex/313 @@ -0,0 +1,3 @@ +Unhandled fault backpatching to sigtrap instruction +On unhandled fault we should be able to backpatch the instruction and rerun it as one that generates sigtrap so we can still backtrace the host in GDB. +Still needs some thinking about, and it would be nice to also do the guest side so we can backtrace in gdbstub. \ No newline at end of file diff --git a/results/scraper/fex/314 b/results/scraper/fex/314 new file mode 100644 index 000000000..9f23f7cc1 --- /dev/null +++ b/results/scraper/fex/314 @@ -0,0 +1,8 @@ +Library for path canonicalization +With our rootfs implementation, we need to support path canonicalization with explicit support for the rootfs as the root directory. +Then on top of that a regular canonicalize that treats `/` as a rootfs as well. +This is required to support both so applications can't trick our path checking + +eg: `/proc/../cpuinfo` would currently trick our emulation and get a real host `/proc/cpuinfo + +eg: `/usr/../../test.txt` would escape the rootfs and load a `test.txt` in the same folder as the rootfs if one existed \ No newline at end of file diff --git a/results/scraper/fex/3143 b/results/scraper/fex/3143 new file mode 100644 index 000000000..3d9f3ca5b --- /dev/null +++ b/results/scraper/fex/3143 @@ -0,0 +1,2 @@ +Strictly correlate registers between inline syscall and RA +This way #3142 can't happen again. \ No newline at end of file diff --git a/results/scraper/fex/3146 b/results/scraper/fex/3146 new file mode 100644 index 000000000..3d4f81001 --- /dev/null +++ b/results/scraper/fex/3146 @@ -0,0 +1,11 @@ +InstCountCI: Support multiple instruction tests +Right now we can't test simple things like cost-prop optimizations. We don't really want huge tests in this CI but smaller things make sense. +eg: +```asm +mov rax, 0 +mov rcx, 0 +cpuid +``` +This would hit a more optimal case but our CI can't show it yet. + +This will require implementing some way to dynamically choose block size to compile and just a list in the json. Likely changing the instruction name in to just a tag. \ No newline at end of file diff --git a/results/scraper/fex/315 b/results/scraper/fex/315 new file mode 100644 index 000000000..613b714a1 --- /dev/null +++ b/results/scraper/fex/315 @@ -0,0 +1,4 @@ +POSIX tests compile ROOTFS env variable in to build +Instead of allowing cmake to embed the ROOTFS environment variable in to the build files, pass the env variable to the posix runner script. +This will solve the problem of running posix tests, but forgetting to set the environment variable, thus requiring a new cmake step prior to just running ctest. +You'll be able to just set the environment variable and immediately run ctest \ No newline at end of file diff --git a/results/scraper/fex/316 b/results/scraper/fex/316 new file mode 100644 index 000000000..dd5373b78 --- /dev/null +++ b/results/scraper/fex/316 @@ -0,0 +1,5 @@ +INT3 support for guest +With signals being supported, INT3 can be properly supported now. +We can either force a sigsegv crash there which the guest signal handler can pick up. +Or we can have it backtrace through gdb stub +or both. \ No newline at end of file diff --git a/results/scraper/fex/3160 b/results/scraper/fex/3160 new file mode 100644 index 000000000..1afe902c6 --- /dev/null +++ b/results/scraper/fex/3160 @@ -0,0 +1,5 @@ +I think we can insert masking on sources retroactively for add/sub in the future. For now this PR should make things strictly better so should probs be merged. + I think we can insert masking on sources retroactively for add/sub in the future. For now this PR should make things strictly better so should probs be merged. + +_Originally posted by @alyssarosenzweig in https://github.com/FEX-Emu/FEX/issues/3154#issuecomment-1735461800_ + \ No newline at end of file diff --git a/results/scraper/fex/317 b/results/scraper/fex/317 new file mode 100644 index 000000000..2c7349068 --- /dev/null +++ b/results/scraper/fex/317 @@ -0,0 +1,5 @@ +Guest thread fixed offset stack allocation needs fixed +Currently the initial guest thread's stack allocation is allocated at a fixed memory offset. +This should be fixed to be allocated at "any" location. +This would be within the lower 32bits for x86, and "anywhere" for x86-64. +There might need to be some special bits here for executable stack but that can be worked out. \ No newline at end of file diff --git a/results/scraper/fex/3175 b/results/scraper/fex/3175 new file mode 100644 index 000000000..4db28c2aa --- /dev/null +++ b/results/scraper/fex/3175 @@ -0,0 +1,12 @@ +Feature request +Hi, + +I'm Mr. Line, a very friendly guy. + +Feature request: + +A one-liner easy installer command for Raspberry Pi 4. I think a lot of us have this device. + +Interesting project, wanted to test it because I haven't really been able to get qemu or Box64 to run on the Raspberry Pi 4 yet. The problem with all three projects I think is that there is no easy installer. Way over-complicated. If you want users, then you should have a one-liner installer. + +Especially interested if FEX can provide a bash prompt where I can do anything as if I were running real hardware. \ No newline at end of file diff --git a/results/scraper/fex/318 b/results/scraper/fex/318 new file mode 100644 index 000000000..f780ce87f --- /dev/null +++ b/results/scraper/fex/318 @@ -0,0 +1,3 @@ +Take advantage of ARMv8.4-RCPC +We aren't currently using this instruction set. We should move over to supporting it to improve memory access performance. +Our Cortex-A76/A55 CPUs support the instructions. \ No newline at end of file diff --git a/results/scraper/fex/319 b/results/scraper/fex/319 new file mode 100644 index 000000000..5a950ad95 --- /dev/null +++ b/results/scraper/fex/319 @@ -0,0 +1,3 @@ +binfmt_misc installer support +We should have the ability to install a binfmt_misc file on AArch64 hosts to automatically install the handler for us. +This won't be hard, just needs to be done. \ No newline at end of file diff --git a/results/scraper/fex/3193 b/results/scraper/fex/3193 new file mode 100644 index 000000000..3988df45b --- /dev/null +++ b/results/scraper/fex/3193 @@ -0,0 +1,5 @@ +We probably want a helper for load with garbage… + We probably want a helper for load with garbage… + +_Originally posted by @alyssarosenzweig in https://github.com/FEX-Emu/FEX/pull/3192#pullrequestreview-1669021867_ + \ No newline at end of file diff --git a/results/scraper/fex/3197 b/results/scraper/fex/3197 new file mode 100644 index 000000000..fb242694a --- /dev/null +++ b/results/scraper/fex/3197 @@ -0,0 +1,53 @@ +BOINC: Couldn't connect to FEXServer socket +**What Game** +This is not a game, but rather I'm evaluating the suitability of FEX to run scientific computing applications. These are CPU bound and do not have graphics. QEMU-user works, but FEX might offer better performance. + +This software might not be relevant to your project goals. In that case, I would appreciate any recommendations of debugging the issue. + +A link to the storefront where to get the game. GOG, Steam, Itch.io, etc + +Boinc client (host native): https://boinc.berkeley.edu/download.php +Application (x86_64, downloaded by the client at runtime, no direct download): https://milkyway.cs.rpi.edu/milkyway/apps.php + +**Describe the bug** +Running MilkyWay directly from the CLI works great via the binfmt_misc mechanism. +However, I get this error when BOINC tries to launch the application binary using the same arguments: + +`[ERROR] Couldn't connect to FEXServer socket 114.FEXServer.Socket 111 Connection refused +[ERROR] Couldn't connect to FEXServer socket 114.FEXServer.Socket 111 Connection refused +[ERROR] Couldn't connect to FEXServer socket 114.FEXServer.Socket 111 Connection refused +[ERROR] Couldn't connect to FEXServer socket 114.FEXServer.Socket 111 Connection refused +[ERROR] Couldn't connect to FEXServer socket 114.FEXServer.Socket 111 Connection refused +[ERROR] Couldn't connect to FEXServer socket 114.FEXServer.Socket after launching the process +[ERROR] FEXServerClient: Failure to setup client` + +Boinc runs as user `boinc` rather than my user. I'm not sure if this can explain the error. + +**To Reproduce** +Steps to reproduce the behavior: +1. Install BOINC. +2. Modify `/etc/boinc/cc_config.xml` to define <alt_platform> to force download of x86_64 executables. +3. Register for MilkyWay and wait for client to download the app. +4. Observe in /var/lib/boinc/projects/milkway/<binary name> that binary appears to initialize correctly when run directly. +5. Observe BOINC reports task failure. Log messages are unfortunately submitted to MilkyWay servers and can be pulled from there in the task listing for the registered machine. + +I need to explore a more precise and self-contained procedure, but I'm more hoping for general ideas rather than for someone to invest their valuable time trying to reproduce a non-game error. + +**Expected behavior** +It shouldn't fail when boinc runs the binary given that it works when run by a normal user. + +**System information:** + - OS: Ubuntu 22 LTS + - CPU/SoC: Raspberry Pi 4 + - Video driver version: N/A + - RootFS used: Default + - FEX version: FEX-2310. I can obtain a more accurate value at a later time upon request. + - Thunks Enabled: Default, not sure. + +**Additional context** + - Is this an x86 or x86-64 game: x86-64 + - Does this reproduce on x86-64 host with FEX: Untested + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: No + +Thank you for your time. diff --git a/results/scraper/fex/320 b/results/scraper/fex/320 new file mode 100644 index 000000000..68dd7a1fb --- /dev/null +++ b/results/scraper/fex/320 @@ -0,0 +1,4 @@ +Program specific config files +We should have the ability to check the program filename and have an overlay config file for it. +This can solve the issue when we know up front that an application is doing evil things and we can change config options to handle it. +Should be easy enough, we just need another layer that loads from `${INSTALL_PREFIX}/fex-emu/configs/<App>.json` and probably also `${HOME}/.config/fex-emu/configs/<App>.json` for user configs. \ No newline at end of file diff --git a/results/scraper/fex/3204 b/results/scraper/fex/3204 new file mode 100644 index 000000000..aa4067e5f --- /dev/null +++ b/results/scraper/fex/3204 @@ -0,0 +1,63 @@ +openat() doesn't ignore dirfd if path is absolute +I'm using FEX 2310, locally built from source according to https://github.com/FEX-Emu/FEX#building-fex, on a Raspberry Pi 4b running the Debian-12-based Raspberry Pi OS; FEX is using an Ubuntu 22.04 rootfs. + +## Steps to reproduce + +Compile this for x86, copy it to the target device and run it: + +``` +#define _GNU_SOURCE +#include <assert.h> +#include <fcntl.h> +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +int main (void) +{ + int res = chdir ("/"); + assert (res == 0); + + int root = openat (AT_FDCWD, "/", O_RDONLY | O_NONBLOCK | O_DIRECTORY | O_CLOEXEC); + printf ("root: %d\n", root); + int fd_abs = openat (root, "/etc/os-release", O_RDONLY | O_CLOEXEC | O_NOCTTY); + printf ("fd,abs: %d\n", fd_abs); + int cwd_abs = openat (AT_FDCWD, "/etc/os-release", O_RDONLY | O_CLOEXEC | O_NOCTTY); + printf ("cwd,abs: %d\n", cwd_abs); + int fd_rel = openat (root, "etc/os-release", O_RDONLY | O_CLOEXEC | O_NOCTTY); + printf ("fd,rel: %d\n", fd_rel); + int cwd_rel = openat (AT_FDCWD, "etc/os-release", O_RDONLY | O_CLOEXEC | O_NOCTTY); + printf ("cwd,rel: %d\n", cwd_rel); + + char *s = NULL; + res = asprintf (&s, "ls -l /proc/%d/fd", getpid ()); + assert (res > 0); + system (s); + return 0; +} +``` + +## Expected result + +The fds identified as `fd,abs` (short for "dirfd = root, path is absolute") and `cwd,abs` (dirfd = AT_FDCWD, path is absolute) point to the `/etc/os-release` from the Ubuntu rootfs, the same one you'd read by `FEXBash -c 'cat /etc/os-release'`. In my case this is really `/home/user/.fex-emu/RootFS/Ubuntu_22_04/usr/lib/os-release`, and `/proc` shows it as such. + +The fds identified as `fd,rel` (dirfd = root, path is relative) and `cwd,rel` (dirfd = AT_FDCWD, path is relative) point to the `/etc/os-release` from the real rootfs, the same one you'd read by `cat /etc/os-release` from an ordinary ARM shell. In my case this is really `/usr/lib/os-release`. + +## Actual result + +The fd identified as `fd,abs` is the real /etc/os-release: FEX is not redirecting it to the rootfs' /etc/os-release. This is not as I expected: the openat(2) man page documents "If the pathname given in pathname is absolute, then dirfd is ignored" and I expected the same thing to be true when using FEX. + +The other three are as I expected. + +## Context + +The `fd,abs` case is a simplification of something I was trying to do in a development branch of Steam's steam-runtime-system-info and pressure-vessel, to make sure that we take FEX's rootfs pseudo-overlay into account when reading information about the real root filesystem. + +## Workaround + +``` +if (path[0] == '/') + fd = AT_FDCWD; +``` + +to force all accesses to absolute paths onto the `cwd,abs` code path, which FEX implements the way I had expected. \ No newline at end of file diff --git a/results/scraper/fex/321 b/results/scraper/fex/321 new file mode 100644 index 000000000..dafd476bc --- /dev/null +++ b/results/scraper/fex/321 @@ -0,0 +1,3 @@ +xmoto still broken? +Haven't had the time to dive in to it, probably still some issue with the SDL font glyph handling. +Needs a more thorough investigation. \ No newline at end of file diff --git a/results/scraper/fex/322 b/results/scraper/fex/322 new file mode 100644 index 000000000..bde439665 --- /dev/null +++ b/results/scraper/fex/322 @@ -0,0 +1,2 @@ +Switch unit tests to use unified memory +Let's kill the non-unified memory path. It's worthless at this point. \ No newline at end of file diff --git a/results/scraper/fex/324 b/results/scraper/fex/324 new file mode 100644 index 000000000..119993bce --- /dev/null +++ b/results/scraper/fex/324 @@ -0,0 +1,2 @@ +Write documentation about debugging FEX with signals +Also with gdbstub \ No newline at end of file diff --git a/results/scraper/fex/3246 b/results/scraper/fex/3246 new file mode 100644 index 000000000..0b911c7b6 --- /dev/null +++ b/results/scraper/fex/3246 @@ -0,0 +1,8 @@ +wine: segmentation fault +when i run wine with fex like +``` +DISPLAY=:1 FEXInterpreter /usr/local/bin/wine64 wineboot +``` +i'm getting segmentation fault, if i try to run it just like `FEXInterpreter wine64` it prints the help message, but if i specify just ANY argument for it (except --help and --version) it segfaults, even if there's no such file/program (like `FEXInterpreter wine64 abcd`) also that problem is same for both wine and wine64 + +P.S. i have fex from ppa, FEXLoader --version says `FEX-Emu (FEX-2309.1)` \ No newline at end of file diff --git a/results/scraper/fex/325 b/results/scraper/fex/325 new file mode 100644 index 000000000..0b22ec848 --- /dev/null +++ b/results/scraper/fex/325 @@ -0,0 +1,2 @@ +Simple applications for unit testing thunks +We need some applications for testing thunks that we can install in to the rootfs. \ No newline at end of file diff --git a/results/scraper/fex/326 b/results/scraper/fex/326 new file mode 100644 index 000000000..0ae79c2f8 --- /dev/null +++ b/results/scraper/fex/326 @@ -0,0 +1,25 @@ +Mono's GC fails on sigaltstack w/ SS_DISABLE +Repro steps + +``` +Bin/ELFLoader -s -c irjit -n 500 -- /usr/bin/mono /usr/lib/mono/4.5/mcs.exe +error CS2008: No files to compile were specified +Compilation failed: 1 error(s), 0 warnings +Mono: GC_MAJOR: (user request) time 50.11ms, stw 77.87ms los size: 0K in use: 0K +Mono: GC_MAJOR_SWEEP: major size: 768K in use: 81K +* Assertion at mini-exceptions.c:3191, condition `err == 0' not met +``` + +Mono Source: https://github.com/mono/mono/blob/master/mono/mini/mini-exceptions.c#L3196 +``` +mono_free_altstack (MonoJitTlsData *tls) +{ + stack_t sa; + int err; + + sa.ss_sp = tls->signal_stack; + sa.ss_size = MONO_ARCH_SIGNAL_STACK_SIZE; + sa.ss_flags = SS_DISABLE; + err = sigaltstack (&sa, NULL); + g_assert (err == 0); +``` \ No newline at end of file diff --git a/results/scraper/fex/3262 b/results/scraper/fex/3262 new file mode 100644 index 000000000..bedbbd99b --- /dev/null +++ b/results/scraper/fex/3262 @@ -0,0 +1,3 @@ +Steam on openFyde Black screen fix? + +Hi is there any bypass for this to run? \ No newline at end of file diff --git a/results/scraper/fex/328 b/results/scraper/fex/328 new file mode 100644 index 000000000..3b268c2da --- /dev/null +++ b/results/scraper/fex/328 @@ -0,0 +1,4 @@ +BTR is not tested sufficiently, doesn't implement fs/gs either +for BTR only the flags side effects are tested, not the register results. #327 fixes at least one bug in it. + +BTR also uses loadsource w/o mem load, but doesn't add the FS/GS as it should. diff --git a/results/scraper/fex/329 b/results/scraper/fex/329 new file mode 100644 index 000000000..3f341073a --- /dev/null +++ b/results/scraper/fex/329 @@ -0,0 +1 @@ +sched_getaffinity is broken diff --git a/results/scraper/fex/3316 b/results/scraper/fex/3316 new file mode 100644 index 000000000..c6e5ca9eb --- /dev/null +++ b/results/scraper/fex/3316 @@ -0,0 +1,31 @@ +Transistor: OutOfMemoryException on start +**What Game** +Transistor +[A link to the storefront where to get the game. GOG, Steam, Itch.io, etc](https://store.steampowered.com/app/237930/Transistor/) + +**Describe the bug** +Mono crashes, reporting an OutOfMemoryException. This is generally not possible to trigger normally with Linux having overcommit. + +**To Reproduce** +1. Start the game, either through steam or running ./Transistor.bin.x86_64 directly +2. Observe the exception in a standard X11 dialog + +**Expected behavior** +Game starts + +**Screenshots and Video** + + + +**System information:** + - OS: Ubuntu 23.10 + - CPU/SoC: BCM2712 4x A76 and VC7 + - RootFS used: Ubuntu 23.04 official, erofs + - FEX version: + - Thunks Enabled: No + +**Additional context** + - Is this an x86 or x86-64 game: Both + - Does this reproduce on x86-64 host with FEX: Untested + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: No \ No newline at end of file diff --git a/results/scraper/fex/3324 b/results/scraper/fex/3324 new file mode 100644 index 000000000..cf5c47887 --- /dev/null +++ b/results/scraper/fex/3324 @@ -0,0 +1,84 @@ +Change the LD_LIBRARY_PATH for native libraries? +Hi there, + +I've just installed FEX-emu on my Android 12 phone running Ubuntu 23.10 in a Proot environment. +In order to get proper OpenGL (using zink) and Vulkan using freedreno's turnip, I've manually compiled mesa from source and installed it in /usr/local/lib64 and /usr/local/lib. + +So I've set: +``` +LIBGL_DRIVERS_PATH=/usr/local/lib64/dri:/usr/local/lib/dri +VK_ICD_FILENAMES=/usr/local/share/vulkan/icd.d/freedreno_icd.aarch64.json:/usr/local/share/vulkan/icd.d/freedreno_icd.armv7l.json +``` +And I've also created a ```/etc/ld.conf.so.d/000-local.conf``` with: +``` +/usr/local/lib64 +/usr/local/lib +``` + +This works great for native things like glxinfo, vkcube and supertuxkart: +``` +$ MESA_LOADER_DRIVER_OVERRIDE=zink glxinfo +... +OpenGL vendor string: Mesa +OpenGL renderer string: zink Vulkan 1.3(Turnip Adreno (TM) 640 (MESA_TURNIP)) +OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.0.0-devel (git-a921a69010) +OpenGL core profile shading language version string: 4.60 +OpenGL core profile context flags: no-error +OpenGL core profile profile mask: core profile +... +$ vkcube +Selected GPU 0: Turnip Adreno (TM) 640, type: IntegratedGpu +``` + +However, when I run steam, it doesn't seem to load the native libGL from /usr/local/lib{,64}: +``` +$ MESA_LOADER_DRIVER_OVERRIDE=zink FEXBash steam + +steam.sh[8786]: Running Steam on ubuntu 23.10 64-bit +steam.sh[8786]: STEAM_RUNTIME is enabled by the user +setup.sh[8858]: Steam runtime environment up-to-date! +steam.sh[8786]: Steam client's requirements are satisfied +[2023-12-12 14:00:46] Startup - updater built Dec 8 2023 00:32:59 +[2023-12-12 14:00:46] Startup - Steam Client launched with: '/home/mastag/.local/share/Steam/ubuntu12_32/steam' +12/12 14:00:46 Init: Installing breakpad exception handler for appid(steam)/version(1702079146)/tid(8884) +MESA-LOADER: failed to open zink: /usr/local/lib/dri/zink_dri.so: cannot open shared object file: No such file or directory (search paths /usr/local/lib64/dri:/usr/local/lib/dri, suffix _dri) +failed to load driver: zink +Looks like steam didn't shutdown cleanly, scheduling immediate update check +[2023-12-12 14:00:53] Loading cached metrics from disk (/home/mastag/.local/share/Steam/package/steam_client_metrics.bin) +[2023-12-12 14:00:53] Failed to load cached hosts file (File 'update_hosts_cached.vdf' not found), using defaults +[2023-12-12 14:00:53] Using the following download hosts for Public, Realm steamglobal +[2023-12-12 14:00:53] 1. https://cdn.steamstatic.com, /client/, Realm 'steamglobal', weight was 1, source = 'baked in' +[2023-12-12 14:00:53] Checking for update on startup +[2023-12-12 14:00:53] Checking for available updates... +[2023-12-12 14:00:53] Downloading manifest: https://cdn.steamstatic.com/client/steam_client_ubuntu12 +[2023-12-12 14:00:53] Manifest download: send request +[2023-12-12 14:00:53] Manifest download: waiting for download to finish +[2023-12-12 14:00:54] Manifest download: finished +[2023-12-12 14:00:54] Download skipped: /client/steam_client_ubuntu12 version 1702079146, installed version 1702079146, existing pending version 0 +[2023-12-12 14:00:54] Nothing to do +[2023-12-12 14:00:54] Verifying installation... +[2023-12-12 14:00:54] Performing checksum verification of executable files +[2023-12-12 14:01:08] Verification complete + +Steam logging initialized: directory: /home/mastag/.local/share/Steam/logs + +XRRGetOutputInfo Workaround: initialized with override: 0 real: 0xf5f3a9c0 +XRRGetCrtcInfo Workaround: initialized with override: 0 real: 0xf5f391f0 +lspci: Cannot open /proc/bus/pci/devices +MESA-LOADER: failed to open zink: /usr/local/lib/dri/zink_dri.so: cannot open shared object file: No such file or directory (search paths /usr/local/lib64/dri:/usr/local/lib/dri, suffix _dri) +failed to load driver: zink +lspci: Cannot open /proc/bus/pci/devices +MESA-LOADER: failed to open zink: /usr/local/lib/dri/zink_dri.so: cannot open shared object file: No such file or directory (search paths /usr/local/lib64/dri:/usr/local/lib/dri, suffix _dri) +failed to load driver: zink +steamwebhelper.sh[8923]: Runtime for steamwebhelper: defaulting to /home/mastag/.local/share/Steam/ubuntu12_64/steam-runtime-heavy +steamwebhelper.sh[8923]: glibc >= 2.34, partially disabling sandbox until CEF supports clone3() +MESA-LOADER: failed to open zink: /usr/local/lib/dri/zink_dri.so: cannot open shared object file: No such file or directory (search paths /usr/local/lib64/dri:/usr/local/lib/dri, suffix _dri) +failed to load driver: zink +glXChooseVisual failed +glXChooseVisual failedsrc/steamUI/spewmanager.cpp (184) : Assertion Failed: Error: glXChooseVisual failed +src/steamUI/spewmanager.cpp (184) : Assertion Failed: Error: glXChooseVisual failed +Error: glXChooseVisual failed12/12 14:01:12 Failed writing minidump, nothing to upload. +/home/mastag/.local/share/Steam/steam.sh: line 798: 8884 Segmentation fault "$STEAMROOT/$STEAMEXEPATH" "$@" +``` + +Any ideas? \ No newline at end of file diff --git a/results/scraper/fex/3328 b/results/scraper/fex/3328 new file mode 100644 index 000000000..11680d91e --- /dev/null +++ b/results/scraper/fex/3328 @@ -0,0 +1,418 @@ +[Compiling Error] Error when compiling Vulkan Thunks +When trying to update FEX-Emu (after quite a while, I'll admit), I get this: +<details> +<summary>Log</summary> +[284/383] Generating gen/thunkgen_guest_libvulkan.inl +FAILED: ThunkLibs/GuestLibs/gen/thunkgen_guest_libvulkan.inl /FEX/Build/ThunkLibs/GuestLibs/gen/thunkgen_guest_libvulkan.inl +cd /FEX/Build/ThunkLibs/GuestLibs && /FEX/Build/Bin/thunkgen /FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp libvulkan -guest /FEX/Build/ThunkLibs/GuestLibs/gen/thunkgen_guest_libvulkan.inl -- -std=c++20 --target=x86_64-linux-unknown -isystem /usr/x86_64-linux-gnu/include/ -DGUEST_THUNK_LIBRARY -isystem/FEX/ThunkLibs/GuestLibs/../include -isystem/FEX/External/Vulkan-Headers/include/ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:49:32: error: unknown type name 'VkDescriptorDataEXT'; did you mean 'VkDescriptorSet'? +template<> struct fex_gen_type<VkDescriptorDataEXT> : fexgen::assume_compatible_data_layout {}; + ^~~~~~~~~~~~~~~~~~~ + VkDescriptorSet +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:119:35: note: 'VkDescriptorSet' declared here +VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkDescriptorSet) + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:322:34: error: use of undeclared identifier 'vkGetPhysicalDeviceVideoCapabilitiesKHR'; did you mean 'vkGetPhysicalDeviceSurfaceCapabilitiesKHR'? +template<> struct fex_gen_config<vkGetPhysicalDeviceVideoCapabilitiesKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + vkGetPhysicalDeviceSurfaceCapabilitiesKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:7573:32: note: 'vkGetPhysicalDeviceSurfaceCapabilitiesKHR' declared here +VKAPI_ATTR VkResult VKAPI_CALL vkGetPhysicalDeviceSurfaceCapabilitiesKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:322:19: error: redefinition of 'fex_gen_config<&vkGetPhysicalDeviceSurfaceCapabilitiesKHR>' +template<> struct fex_gen_config<vkGetPhysicalDeviceVideoCapabilitiesKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:302:19: note: previous definition is here +template<> struct fex_gen_config<vkGetPhysicalDeviceSurfaceCapabilitiesKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:323:34: error: use of undeclared identifier 'vkGetPhysicalDeviceVideoFormatPropertiesKHR' +template<> struct fex_gen_config<vkGetPhysicalDeviceVideoFormatPropertiesKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:324:34: error: use of undeclared identifier 'vkCreateVideoSessionKHR' +template<> struct fex_gen_config<vkCreateVideoSessionKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:325:34: error: use of undeclared identifier 'vkDestroyVideoSessionKHR' +template<> struct fex_gen_config<vkDestroyVideoSessionKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:326:34: error: use of undeclared identifier 'vkGetVideoSessionMemoryRequirementsKHR'; did you mean 'vkGetDeviceImageMemoryRequirementsKHR'? +template<> struct fex_gen_config<vkGetVideoSessionMemoryRequirementsKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + vkGetDeviceImageMemoryRequirementsKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:9765:28: note: 'vkGetDeviceImageMemoryRequirementsKHR' declared here +VKAPI_ATTR void VKAPI_CALL vkGetDeviceImageMemoryRequirementsKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:327:34: error: use of undeclared identifier 'vkBindVideoSessionMemoryKHR' +template<> struct fex_gen_config<vkBindVideoSessionMemoryKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:328:34: error: use of undeclared identifier 'vkCreateVideoSessionParametersKHR' +template<> struct fex_gen_config<vkCreateVideoSessionParametersKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:329:34: error: use of undeclared identifier 'vkUpdateVideoSessionParametersKHR' +template<> struct fex_gen_config<vkUpdateVideoSessionParametersKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:330:34: error: use of undeclared identifier 'vkDestroyVideoSessionParametersKHR' +template<> struct fex_gen_config<vkDestroyVideoSessionParametersKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:331:34: error: use of undeclared identifier 'vkCmdBeginVideoCodingKHR'; did you mean 'vkCmdBeginRenderingKHR'? +template<> struct fex_gen_config<vkCmdBeginVideoCodingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~ + vkCmdBeginRenderingKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:7957:28: note: 'vkCmdBeginRenderingKHR' declared here +VKAPI_ATTR void VKAPI_CALL vkCmdBeginRenderingKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:332:34: error: use of undeclared identifier 'vkCmdEndVideoCodingKHR'; did you mean 'vkCmdEndRenderingKHR'? +template<> struct fex_gen_config<vkCmdEndVideoCodingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~ + vkCmdEndRenderingKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:7961:28: note: 'vkCmdEndRenderingKHR' declared here +VKAPI_ATTR void VKAPI_CALL vkCmdEndRenderingKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:333:34: error: use of undeclared identifier 'vkCmdControlVideoCodingKHR' +template<> struct fex_gen_config<vkCmdControlVideoCodingKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:334:34: error: use of undeclared identifier 'vkCmdDecodeVideoKHR' +template<> struct fex_gen_config<vkCmdDecodeVideoKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:335:19: error: redefinition of 'fex_gen_config<&vkCmdBeginRenderingKHR>' +template<> struct fex_gen_config<vkCmdBeginRenderingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:331:19: note: previous definition is here +template<> struct fex_gen_config<vkCmdBeginVideoCodingKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:336:19: error: redefinition of 'fex_gen_config<&vkCmdEndRenderingKHR>' +template<> struct fex_gen_config<vkCmdEndRenderingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:332:19: note: previous definition is here +template<> struct fex_gen_config<vkCmdEndVideoCodingKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:407:34: error: use of undeclared identifier 'vkMapMemory2KHR'; did you mean 'vkMapMemory'? +template<> struct fex_gen_config<vkMapMemory2KHR> {}; + ^~~~~~~~~~~~~~~ + vkMapMemory +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:4125:32: note: 'vkMapMemory' declared here +VKAPI_ATTR VkResult VKAPI_CALL vkMapMemory( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:407:19: error: redefinition of 'fex_gen_config<&vkMapMemory>' +template<> struct fex_gen_config<vkMapMemory2KHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:106:19: note: previous definition is here +template<> struct fex_gen_config<vkMapMemory> {}; + ^ +fatal error: too many errors emitted, stopping now [-ferror-limit=] +20 errors generated. +Error while processing /FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp. +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:49:32: error: unknown type name 'VkDescriptorDataEXT'; did you mean 'VkDescriptorSet'? +template<> struct fex_gen_type<VkDescriptorDataEXT> : fexgen::assume_compatible_data_layout {}; + ^~~~~~~~~~~~~~~~~~~ + VkDescriptorSet +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:119:35: note: 'VkDescriptorSet' declared here +VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkDescriptorSet) + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:322:34: error: use of undeclared identifier 'vkGetPhysicalDeviceVideoCapabilitiesKHR'; did you mean 'vkGetPhysicalDeviceSurfaceCapabilitiesKHR'? +template<> struct fex_gen_config<vkGetPhysicalDeviceVideoCapabilitiesKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + vkGetPhysicalDeviceSurfaceCapabilitiesKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:7573:32: note: 'vkGetPhysicalDeviceSurfaceCapabilitiesKHR' declared here +VKAPI_ATTR VkResult VKAPI_CALL vkGetPhysicalDeviceSurfaceCapabilitiesKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:322:19: error: redefinition of 'fex_gen_config<&vkGetPhysicalDeviceSurfaceCapabilitiesKHR>' +template<> struct fex_gen_config<vkGetPhysicalDeviceVideoCapabilitiesKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:302:19: note: previous definition is here +template<> struct fex_gen_config<vkGetPhysicalDeviceSurfaceCapabilitiesKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:323:34: error: use of undeclared identifier 'vkGetPhysicalDeviceVideoFormatPropertiesKHR' +template<> struct fex_gen_config<vkGetPhysicalDeviceVideoFormatPropertiesKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:324:34: error: use of undeclared identifier 'vkCreateVideoSessionKHR' +template<> struct fex_gen_config<vkCreateVideoSessionKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:325:34: error: use of undeclared identifier 'vkDestroyVideoSessionKHR' +template<> struct fex_gen_config<vkDestroyVideoSessionKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:326:34: error: use of undeclared identifier 'vkGetVideoSessionMemoryRequirementsKHR'; did you mean 'vkGetDeviceImageMemoryRequirementsKHR'? +template<> struct fex_gen_config<vkGetVideoSessionMemoryRequirementsKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + vkGetDeviceImageMemoryRequirementsKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:9765:28: note: 'vkGetDeviceImageMemoryRequirementsKHR' declared here +VKAPI_ATTR void VKAPI_CALL vkGetDeviceImageMemoryRequirementsKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:327:34: error: use of undeclared identifier 'vkBindVideoSessionMemoryKHR' +template<> struct fex_gen_config<vkBindVideoSessionMemoryKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:328:34: error: use of undeclared identifier 'vkCreateVideoSessionParametersKHR' +template<> struct fex_gen_config<vkCreateVideoSessionParametersKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:329:34: error: use of undeclared identifier 'vkUpdateVideoSessionParametersKHR' +template<> struct fex_gen_config<vkUpdateVideoSessionParametersKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:330:34: error: use of undeclared identifier 'vkDestroyVideoSessionParametersKHR' +template<> struct fex_gen_config<vkDestroyVideoSessionParametersKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:331:34: error: use of undeclared identifier 'vkCmdBeginVideoCodingKHR'; did you mean 'vkCmdBeginRenderingKHR'? +template<> struct fex_gen_config<vkCmdBeginVideoCodingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~ + vkCmdBeginRenderingKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:7957:28: note: 'vkCmdBeginRenderingKHR' declared here +VKAPI_ATTR void VKAPI_CALL vkCmdBeginRenderingKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:332:34: error: use of undeclared identifier 'vkCmdEndVideoCodingKHR'; did you mean 'vkCmdEndRenderingKHR'? +template<> struct fex_gen_config<vkCmdEndVideoCodingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~ + vkCmdEndRenderingKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:7961:28: note: 'vkCmdEndRenderingKHR' declared here +VKAPI_ATTR void VKAPI_CALL vkCmdEndRenderingKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:333:34: error: use of undeclared identifier 'vkCmdControlVideoCodingKHR' +template<> struct fex_gen_config<vkCmdControlVideoCodingKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:334:34: error: use of undeclared identifier 'vkCmdDecodeVideoKHR' +template<> struct fex_gen_config<vkCmdDecodeVideoKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:335:19: error: redefinition of 'fex_gen_config<&vkCmdBeginRenderingKHR>' +template<> struct fex_gen_config<vkCmdBeginRenderingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:331:19: note: previous definition is here +template<> struct fex_gen_config<vkCmdBeginVideoCodingKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:336:19: error: redefinition of 'fex_gen_config<&vkCmdEndRenderingKHR>' +template<> struct fex_gen_config<vkCmdEndRenderingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:332:19: note: previous definition is here +template<> struct fex_gen_config<vkCmdEndVideoCodingKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:407:34: error: use of undeclared identifier 'vkMapMemory2KHR'; did you mean 'vkMapMemory'? +template<> struct fex_gen_config<vkMapMemory2KHR> {}; + ^~~~~~~~~~~~~~~ + vkMapMemory +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:4125:32: note: 'vkMapMemory' declared here +VKAPI_ATTR VkResult VKAPI_CALL vkMapMemory( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:407:19: error: redefinition of 'fex_gen_config<&vkMapMemory>' +template<> struct fex_gen_config<vkMapMemory2KHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:106:19: note: previous definition is here +template<> struct fex_gen_config<vkMapMemory> {}; + ^ +fatal error: too many errors emitted, stopping now [-ferror-limit=] +20 errors generated. +Error while processing /FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp. +[285/383] Performing build step for 'guest-libs' +FAILED: guest-libs/src/guest-libs-stamp/guest-libs-build /FEX/Build/guest-libs/src/guest-libs-stamp/guest-libs-build +cd /FEX/Build/Guest && /usr/bin/cmake --build . +[1/65] Building CXX object CMakeFiles/X11.dir/FEX/ThunkLibs/libX11/libX11_NativeGuest.cpp.o +[2/65] Generating gen/thunkgen_guest_libEGL.inl +[3/65] Generating gen/thunkgen_guest_libXrender.inl +[4/65] Linking CXX shared library libX11.so +[5/65] Generating gen/thunkgen_guest_libXext.inl +[6/65] Generating gen/thunkgen_guest_libasound.inl +[7/65] Generating gen/thunkgen_guest_libX11.inl +[8/65] Building CXX object CMakeFiles/EGL-guest.dir/FEX/ThunkLibs/libEGL/libEGL_Guest.cpp.o +[9/65] Building CXX object CMakeFiles/Xrender-guest.dir/FEX/ThunkLibs/libXrender/libXrender_Guest.cpp.o +[10/65] Linking CXX shared library libEGL-guest.so +[11/65] Linking CXX shared library libXrender-guest.so +[12/65] Building CXX object CMakeFiles/Xext-guest.dir/FEX/ThunkLibs/libXext/libXext_Guest.cpp.o +[13/65] Generating gen/thunkgen_guest_libGL.inl +[14/65] Generating gen/thunkgen_guest_libXfixes.inl +[15/65] Linking CXX shared library libXext-guest.so +[16/65] Building CXX object CMakeFiles/Xfixes-guest.dir/FEX/ThunkLibs/libXfixes/libXfixes_Guest.cpp.o +[17/65] Generating gen/thunkgen_guest_libxcb.inl +[18/65] Generating gen/thunkgen_guest_libvulkan.inl +FAILED: gen/thunkgen_guest_libvulkan.inl /FEX/Build/Guest/gen/thunkgen_guest_libvulkan.inl +cd /FEX/Build/Guest && /FEX/Build/Bin/thunkgen /FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp libvulkan -guest /FEX/Build/Guest/gen/thunkgen_guest_libvulkan.inl -- -std=c++20 --target=x86_64-linux-unknown -isystem /usr/x86_64-linux-gnu/include/ -DGUEST_THUNK_LIBRARY -isystem/FEX/ThunkLibs/GuestLibs/../include -isystem/FEX/External/Vulkan-Headers/include/ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:49:32: error: unknown type name 'VkDescriptorDataEXT'; did you mean 'VkDescriptorSet'? +template<> struct fex_gen_type<VkDescriptorDataEXT> : fexgen::assume_compatible_data_layout {}; + ^~~~~~~~~~~~~~~~~~~ + VkDescriptorSet +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:119:35: note: 'VkDescriptorSet' declared here +VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkDescriptorSet) + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:322:34: error: use of undeclared identifier 'vkGetPhysicalDeviceVideoCapabilitiesKHR'; did you mean 'vkGetPhysicalDeviceSurfaceCapabilitiesKHR'? +template<> struct fex_gen_config<vkGetPhysicalDeviceVideoCapabilitiesKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + vkGetPhysicalDeviceSurfaceCapabilitiesKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:7573:32: note: 'vkGetPhysicalDeviceSurfaceCapabilitiesKHR' declared here +VKAPI_ATTR VkResult VKAPI_CALL vkGetPhysicalDeviceSurfaceCapabilitiesKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:322:19: error: redefinition of 'fex_gen_config<&vkGetPhysicalDeviceSurfaceCapabilitiesKHR>' +template<> struct fex_gen_config<vkGetPhysicalDeviceVideoCapabilitiesKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:302:19: note: previous definition is here +template<> struct fex_gen_config<vkGetPhysicalDeviceSurfaceCapabilitiesKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:323:34: error: use of undeclared identifier 'vkGetPhysicalDeviceVideoFormatPropertiesKHR' +template<> struct fex_gen_config<vkGetPhysicalDeviceVideoFormatPropertiesKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:324:34: error: use of undeclared identifier 'vkCreateVideoSessionKHR' +template<> struct fex_gen_config<vkCreateVideoSessionKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:325:34: error: use of undeclared identifier 'vkDestroyVideoSessionKHR' +template<> struct fex_gen_config<vkDestroyVideoSessionKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:326:34: error: use of undeclared identifier 'vkGetVideoSessionMemoryRequirementsKHR'; did you mean 'vkGetDeviceImageMemoryRequirementsKHR'? +template<> struct fex_gen_config<vkGetVideoSessionMemoryRequirementsKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + vkGetDeviceImageMemoryRequirementsKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:9765:28: note: 'vkGetDeviceImageMemoryRequirementsKHR' declared here +VKAPI_ATTR void VKAPI_CALL vkGetDeviceImageMemoryRequirementsKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:327:34: error: use of undeclared identifier 'vkBindVideoSessionMemoryKHR' +template<> struct fex_gen_config<vkBindVideoSessionMemoryKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:328:34: error: use of undeclared identifier 'vkCreateVideoSessionParametersKHR' +template<> struct fex_gen_config<vkCreateVideoSessionParametersKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:329:34: error: use of undeclared identifier 'vkUpdateVideoSessionParametersKHR' +template<> struct fex_gen_config<vkUpdateVideoSessionParametersKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:330:34: error: use of undeclared identifier 'vkDestroyVideoSessionParametersKHR' +template<> struct fex_gen_config<vkDestroyVideoSessionParametersKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:331:34: error: use of undeclared identifier 'vkCmdBeginVideoCodingKHR'; did you mean 'vkCmdBeginRenderingKHR'? +template<> struct fex_gen_config<vkCmdBeginVideoCodingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~ + vkCmdBeginRenderingKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:7957:28: note: 'vkCmdBeginRenderingKHR' declared here +VKAPI_ATTR void VKAPI_CALL vkCmdBeginRenderingKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:332:34: error: use of undeclared identifier 'vkCmdEndVideoCodingKHR'; did you mean 'vkCmdEndRenderingKHR'? +template<> struct fex_gen_config<vkCmdEndVideoCodingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~ + vkCmdEndRenderingKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:7961:28: note: 'vkCmdEndRenderingKHR' declared here +VKAPI_ATTR void VKAPI_CALL vkCmdEndRenderingKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:333:34: error: use of undeclared identifier 'vkCmdControlVideoCodingKHR' +template<> struct fex_gen_config<vkCmdControlVideoCodingKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:334:34: error: use of undeclared identifier 'vkCmdDecodeVideoKHR' +template<> struct fex_gen_config<vkCmdDecodeVideoKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:335:19: error: redefinition of 'fex_gen_config<&vkCmdBeginRenderingKHR>' +template<> struct fex_gen_config<vkCmdBeginRenderingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:331:19: note: previous definition is here +template<> struct fex_gen_config<vkCmdBeginVideoCodingKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:336:19: error: redefinition of 'fex_gen_config<&vkCmdEndRenderingKHR>' +template<> struct fex_gen_config<vkCmdEndRenderingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:332:19: note: previous definition is here +template<> struct fex_gen_config<vkCmdEndVideoCodingKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:407:34: error: use of undeclared identifier 'vkMapMemory2KHR'; did you mean 'vkMapMemory'? +template<> struct fex_gen_config<vkMapMemory2KHR> {}; + ^~~~~~~~~~~~~~~ + vkMapMemory +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:4125:32: note: 'vkMapMemory' declared here +VKAPI_ATTR VkResult VKAPI_CALL vkMapMemory( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:407:19: error: redefinition of 'fex_gen_config<&vkMapMemory>' +template<> struct fex_gen_config<vkMapMemory2KHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:106:19: note: previous definition is here +template<> struct fex_gen_config<vkMapMemory> {}; + ^ +fatal error: too many errors emitted, stopping now [-ferror-limit=] +20 errors generated. +Error while processing /FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp. +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:49:32: error: unknown type name 'VkDescriptorDataEXT'; did you mean 'VkDescriptorSet'? +template<> struct fex_gen_type<VkDescriptorDataEXT> : fexgen::assume_compatible_data_layout {}; + ^~~~~~~~~~~~~~~~~~~ + VkDescriptorSet +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:119:35: note: 'VkDescriptorSet' declared here +VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkDescriptorSet) + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:322:34: error: use of undeclared identifier 'vkGetPhysicalDeviceVideoCapabilitiesKHR'; did you mean 'vkGetPhysicalDeviceSurfaceCapabilitiesKHR'? +template<> struct fex_gen_config<vkGetPhysicalDeviceVideoCapabilitiesKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + vkGetPhysicalDeviceSurfaceCapabilitiesKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:7573:32: note: 'vkGetPhysicalDeviceSurfaceCapabilitiesKHR' declared here +VKAPI_ATTR VkResult VKAPI_CALL vkGetPhysicalDeviceSurfaceCapabilitiesKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:322:19: error: redefinition of 'fex_gen_config<&vkGetPhysicalDeviceSurfaceCapabilitiesKHR>' +template<> struct fex_gen_config<vkGetPhysicalDeviceVideoCapabilitiesKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:302:19: note: previous definition is here +template<> struct fex_gen_config<vkGetPhysicalDeviceSurfaceCapabilitiesKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:323:34: error: use of undeclared identifier 'vkGetPhysicalDeviceVideoFormatPropertiesKHR' +template<> struct fex_gen_config<vkGetPhysicalDeviceVideoFormatPropertiesKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:324:34: error: use of undeclared identifier 'vkCreateVideoSessionKHR' +template<> struct fex_gen_config<vkCreateVideoSessionKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:325:34: error: use of undeclared identifier 'vkDestroyVideoSessionKHR' +template<> struct fex_gen_config<vkDestroyVideoSessionKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:326:34: error: use of undeclared identifier 'vkGetVideoSessionMemoryRequirementsKHR'; did you mean 'vkGetDeviceImageMemoryRequirementsKHR'? +template<> struct fex_gen_config<vkGetVideoSessionMemoryRequirementsKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + vkGetDeviceImageMemoryRequirementsKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:9765:28: note: 'vkGetDeviceImageMemoryRequirementsKHR' declared here +VKAPI_ATTR void VKAPI_CALL vkGetDeviceImageMemoryRequirementsKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:327:34: error: use of undeclared identifier 'vkBindVideoSessionMemoryKHR' +template<> struct fex_gen_config<vkBindVideoSessionMemoryKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:328:34: error: use of undeclared identifier 'vkCreateVideoSessionParametersKHR' +template<> struct fex_gen_config<vkCreateVideoSessionParametersKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:329:34: error: use of undeclared identifier 'vkUpdateVideoSessionParametersKHR' +template<> struct fex_gen_config<vkUpdateVideoSessionParametersKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:330:34: error: use of undeclared identifier 'vkDestroyVideoSessionParametersKHR' +template<> struct fex_gen_config<vkDestroyVideoSessionParametersKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:331:34: error: use of undeclared identifier 'vkCmdBeginVideoCodingKHR'; did you mean 'vkCmdBeginRenderingKHR'? +template<> struct fex_gen_config<vkCmdBeginVideoCodingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~ + vkCmdBeginRenderingKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:7957:28: note: 'vkCmdBeginRenderingKHR' declared here +VKAPI_ATTR void VKAPI_CALL vkCmdBeginRenderingKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:332:34: error: use of undeclared identifier 'vkCmdEndVideoCodingKHR'; did you mean 'vkCmdEndRenderingKHR'? +template<> struct fex_gen_config<vkCmdEndVideoCodingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~ + vkCmdEndRenderingKHR +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:7961:28: note: 'vkCmdEndRenderingKHR' declared here +VKAPI_ATTR void VKAPI_CALL vkCmdEndRenderingKHR( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:333:34: error: use of undeclared identifier 'vkCmdControlVideoCodingKHR' +template<> struct fex_gen_config<vkCmdControlVideoCodingKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:334:34: error: use of undeclared identifier 'vkCmdDecodeVideoKHR' +template<> struct fex_gen_config<vkCmdDecodeVideoKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:335:19: error: redefinition of 'fex_gen_config<&vkCmdBeginRenderingKHR>' +template<> struct fex_gen_config<vkCmdBeginRenderingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:331:19: note: previous definition is here +template<> struct fex_gen_config<vkCmdBeginVideoCodingKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:336:19: error: redefinition of 'fex_gen_config<&vkCmdEndRenderingKHR>' +template<> struct fex_gen_config<vkCmdEndRenderingKHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:332:19: note: previous definition is here +template<> struct fex_gen_config<vkCmdEndVideoCodingKHR> {}; + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:407:34: error: use of undeclared identifier 'vkMapMemory2KHR'; did you mean 'vkMapMemory'? +template<> struct fex_gen_config<vkMapMemory2KHR> {}; + ^~~~~~~~~~~~~~~ + vkMapMemory +/FEX/External/Vulkan-Headers/include/vulkan/vulkan_core.h:4125:32: note: 'vkMapMemory' declared here +VKAPI_ATTR VkResult VKAPI_CALL vkMapMemory( + ^ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:407:19: error: redefinition of 'fex_gen_config<&vkMapMemory>' +template<> struct fex_gen_config<vkMapMemory2KHR> {}; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp:106:19: note: previous definition is here +template<> struct fex_gen_config<vkMapMemory> {}; + ^ +fatal error: too many errors emitted, stopping now [-ferror-limit=] +20 errors generated. +Error while processing /FEX/ThunkLibs/GuestLibs/../libvulkan/libvulkan_interface.cpp. +[19/65] Linking CXX shared library libXfixes-guest.so +[20/65] Building CXX object CMakeFiles/asound-guest.dir/FEX/ThunkLibs/libasound/libasound_Guest.cpp.o +[21/65] Building CXX object CMakeFiles/X11-guest.dir/FEX/ThunkLibs/libX11/libX11_Guest.cpp.o +</details> \ No newline at end of file diff --git a/results/scraper/fex/3343 b/results/scraper/fex/3343 new file mode 100644 index 000000000..6226a965c --- /dev/null +++ b/results/scraper/fex/3343 @@ -0,0 +1,4 @@ +Syscall instruction doesn't set RCX and R11 correctly +Syscall is supposed to set RCX to the RIP following the instruction and R11 to the EFLAGS. +This is so the kernel can then use `Sysret` which moves these registers back to RIP and EFLAGS. +Noticed this in a new unittest I'm writing. \ No newline at end of file diff --git a/results/scraper/fex/3347 b/results/scraper/fex/3347 new file mode 100644 index 000000000..bef0eda83 --- /dev/null +++ b/results/scraper/fex/3347 @@ -0,0 +1,121 @@ +ULTRAKILL: Starting the game creates no window and crashes +**What Game** +ULTRAKILL +Unity Engine +Full game: https://store.steampowered.com/app/1229490/ULTRAKILL/ +Demo (May be based on an older Unity version, has the same problem though): 1230260 + +**Describe the bug** +Clicking Play creates no window (most of the time, if it does it black screens and hangs), after a bit it crashes. + +**To Reproduce** +Steps to reproduce the behavior: +1. Launch the game using proton-experimental +2. Observe that it crashes + +**Expected behavior** +The game creates a window and shows some sort of output + +**Steam log (please let me know if you need other logs)** +``` +/bin/sh\0-c\0/home/jja2000/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=1229490 -- /home/jja2000/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- '/home/jja2000/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper'/_v2-entry-point --verb=waitforexitandrun -- '/home/jja2000/.local/share/Steam/steamapps/common/Proton - Experimental'/proton waitforexitandrun '/home/jja2000/.local/share/Steam/steamapps/common/ULTRAKILL/ULTRAKILL.exe'\0 +chdir "/home/jja2000/.local/share/Steam/steamapps/common/ULTRAKILL" +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +pressure-vessel-wrap[30145]: W: The dynamic linker expansion of "$PLATFORM" is not what we expected, VDPAU drivers might not work: Unable to find the library: ${ORIGIN}/x86_64-linux-gnu/${PLATFORM}/libidentify-platform.so: cannot open shared object file: No such file or directory + +pressure-vessel-wrap[30145]: Internal error: /home/jja2000/.local/share/vulkan/implicit_layer.d/steamfossilize_i386.json is not in /usr/lib/pressure-vessel/overrides/share/vulkan/implicit_layer.d +pressure-vessel-wrap[30145]: Internal error: /home/jja2000/.local/share/vulkan/implicit_layer.d/steamfossilize_x86_64.json is not in /usr/lib/pressure-vessel/overrides/share/vulkan/implicit_layer.d +pressure-vessel-wrap[30145]: Internal error: /home/jja2000/.local/share/vulkan/implicit_layer.d/steamoverlay_i386.json is not in /usr/lib/pressure-vessel/overrides/share/vulkan/implicit_layer.d +pressure-vessel-wrap[30145]: Internal error: /home/jja2000/.local/share/vulkan/implicit_layer.d/steamoverlay_x86_64.json is not in /usr/lib/pressure-vessel/overrides/share/vulkan/implicit_layer.d +pressure-vessel-wrap[30145]: Internal error: /usr/share/vulkan/implicit_layer.d/VkLayer_MESA_device_select.json is not in /usr/lib/pressure-vessel/overrides/share/vulkan/implicit_layer.d +pressure-vessel-adverb[30233]: W: Unknown expansion of the dl string token $PLATFORM: Unable to find the library: ${ORIGIN}/x86_64-linux-gnu/${PLATFORM}/libidentify-platform.so: cannot open shared object file: No such file or directory + +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +fsync: up and running. +wine: RLIMIT_NICE is <= 20, unable to use setpriority safely +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +Setting breakpad minidump AppID = 1229490 +Steam_SetMinidumpSteamID: Caching Steam ID: 76561198062667502 [API loaded no] +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +ERROR: ld.so: object '/home/jja2000/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. +``` + +**System information:** + - OS: Fedora Rawhide (40) + - CPU/SoC: Snapdragon 8CX Gen 3 + - Video driver version: Mesa 23.3.1, 23.3.0 in the Fedora 38 rootfs + - RootFS used: Fedora 38 created by FEXRootFSFetcher + - FEX version:FEX-2312-71-gb1c3737 + - Thunks Enabled: No + +**Additional context** + - Is this an x86 or x86-64 game: x86-64 + - Does this reproduce on x86-64 host with FEX: Untested + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: No, using proton-experimental. vk driver is turnip. + +Talked with @Sonicadvance1. Could be a Unity GC problem. \ No newline at end of file diff --git a/results/scraper/fex/3359 b/results/scraper/fex/3359 new file mode 100644 index 000000000..0844d6698 --- /dev/null +++ b/results/scraper/fex/3359 @@ -0,0 +1,7 @@ +'ubuntu 20.04' is not a supported distro +Trying to run installer script: + +ubuntu@testsite~$ curl --silent https://raw.githubusercontent.com/FEX-Emu/FEX/main/Scripts/InstallFEX.py --output /tmp/InstallFEX.py && python3 /tmp/InstallFEX.py && rm /tmp/InstallFEX.py +'ubuntu 20.04' is not a supported distro + +Any workaround ? diff --git a/results/scraper/fex/3360 b/results/scraper/fex/3360 new file mode 100644 index 000000000..1ad0556b6 --- /dev/null +++ b/results/scraper/fex/3360 @@ -0,0 +1,10 @@ +Very unstable steam: self-closing popups and freezes +Currently running FEX on krunvm, which in turn is running on Asahi Fedora Remix (GNOME), hardware is an M1 13' MacBook Pro w/ 8GiB RAM and 256GB SSD. + +When I try running steam, it's very hit & miss, but I managed to see some patterns in the seemingly neverending issues: + +- Dropdowns and popups immediately disappear, one in about 50 cases happens to stay +- Freeze when the display is woken up from sleep (5 minutes idle -> system goes to sleep and locks, Steam freezes after unlocking) +- Freeze when opening a file selection window (add library drive) + +I'll be happy to provide any additional info I might've missed. \ No newline at end of file diff --git a/results/scraper/fex/3364 b/results/scraper/fex/3364 new file mode 100644 index 000000000..c1678a692 --- /dev/null +++ b/results/scraper/fex/3364 @@ -0,0 +1,30 @@ +Using STNT1B to implement MOVNTDQ +As the title says. ASIMD only has STNP which doesn't match semantics. Using STNT1B to match semantics. +Although execution latency is not great on A715 for this instruction. (It gets a bit better on Neoverse-V2). + +Found with a hot-loop in d3dcore.dll in Proton doing a non-temporal memcpy. Consuming about 1.5% CPU time. +``` +1caf3a020 movdqa xmm4, xmmword [r10+rax] +1caf3a026 movntdq xmmword [rcx+rax], xmm4 +1caf3a02b add rax, 0x10 +1caf3a02f cmp rdx, rax +1caf3a032 ja 0x1caf3a020 +``` +rdx is 0x1500 in the hot loop that I found + +``` + 0x00007ffac21cc384: adr x0, 0x7ffac21cc380 + 0x00007ffac21cc388: str x0, [x28, #184] + 0x00007ffac21cc38c: ldr q20, [x4, x14, sxtx] + 0x00007ffac21cc390: str q20, [x4, x5, sxtx] +=> 0x00007ffac21cc394: add x4, x4, #0x10 + 0x00007ffac21cc398: sub x26, x6, x4 + 0x00007ffac21cc39c: eor x27, x6, x4 + 0x00007ffac21cc3a0: cmp x6, x4 + 0x00007ffac21cc3a4: cfinv + 0x00007ffac21cc3a8: cset x20, cc // cc = lo, ul, last + 0x00007ffac21cc3ac: csel x20, x20, xzr, ne // ne = any + 0x00007ffac21cc3b0: cbnz x20, 0x7ffac21cc38c + 0x00007ffac21cc3b4: b 0x7ffac21cc3f0 + 0x00007ffac21cc3b8: blr x0 +``` \ No newline at end of file diff --git a/results/scraper/fex/3369 b/results/scraper/fex/3369 new file mode 100644 index 000000000..af9fc7b1f --- /dev/null +++ b/results/scraper/fex/3369 @@ -0,0 +1,3 @@ +Update gfxreconstruct in the rootfs +It's old an outdated. +Using a commit from Jul 14, 2022 \ No newline at end of file diff --git a/results/scraper/fex/3370 b/results/scraper/fex/3370 new file mode 100644 index 000000000..136d2c6c4 --- /dev/null +++ b/results/scraper/fex/3370 @@ -0,0 +1,3 @@ +Build and install renderdoc in Ubuntu 23.10 image +It was forgotten about. +Could probably update the version shipped as well. \ No newline at end of file diff --git a/results/scraper/fex/3388 b/results/scraper/fex/3388 new file mode 100644 index 000000000..85fcf3ae1 --- /dev/null +++ b/results/scraper/fex/3388 @@ -0,0 +1,38 @@ +Fix steamwebhelper panic spill +As seen in #3389 + +Quite a large amount of panic spilling: +``` +[DEBUG] Panic spilling %61, Live Range[61, 128) +[DEBUG] Panic spilling %185, Live Range[185, 246) +[DEBUG] Panic spilling %350, Live Range[350, 411) +[DEBUG] Panic spilling %467, Live Range[467, 528) +[DEBUG] Panic spilling %629, Live Range[629, 690) +[DEBUG] Panic spilling %746, Live Range[746, 807) +[DEBUG] Panic spilling %908, Live Range[908, 969) +[DEBUG] Panic spilling %1025, Live Range[1025, 1086) +[DEBUG] Panic spilling %1187, Live Range[1187, 1248) +[DEBUG] Panic spilling %1304, Live Range[1304, 1365) +[DEBUG] Panic spilling %1466, Live Range[1466, 1527) +[DEBUG] Panic spilling %1583, Live Range[1583, 1644) +[DEBUG] Panic spilling %1745, Live Range[1745, 1806) +[DEBUG] Panic spilling %1862, Live Range[1862, 1923) +[DEBUG] Panic spilling %2024, Live Range[2024, 2085) +[DEBUG] Panic spilling %2141, Live Range[2141, 2202) +[DEBUG] Panic spilling %2303, Live Range[2303, 2364) +[DEBUG] Panic spilling %2420, Live Range[2420, 2481) +[DEBUG] Panic spilling %2582, Live Range[2582, 2643) +[DEBUG] Panic spilling %2699, Live Range[2699, 2760) +[DEBUG] Panic spilling %2861, Live Range[2861, 2922) +[DEBUG] Panic spilling %2978, Live Range[2978, 3039) +[DEBUG] Panic spilling %3140, Live Range[3140, 3201) +[DEBUG] Panic spilling %3257, Live Range[3257, 3318) +[DEBUG] Panic spilling %3429, Live Range[3429, 3490) +[DEBUG] Panic spilling %3546, Live Range[3546, 3607) +[DEBUG] Panic spilling %3662, Live Range[3662, 3723) +[DEBUG] Panic spilling %3779, Live Range[3779, 3840) +[DEBUG] Panic spilling %3895, Live Range[3895, 3956) +[DEBUG] Panic spilling %4012, Live Range[4012, 4073) +[DEBUG] Panic spilling %4128, Live Range[4128, 4189) +[DEBUG] Panic spilling %4245, Live Range[4245, 4306) +``` \ No newline at end of file diff --git a/results/scraper/fex/3418 b/results/scraper/fex/3418 new file mode 100644 index 000000000..9fa961676 --- /dev/null +++ b/results/scraper/fex/3418 @@ -0,0 +1,26 @@ +steamcmd: When I tried to run "steamcmd", I received an error "./teamcmd. sh: line 38: 8511 Illegal instruction $DEBUGGER" $STEAMEXE "" $@ " +**What Game** +steamcmd + +When I tried to run "steamcmd", I received an error "./teamcmd. sh: line 38: 8511 Illegal instruction $DEBUGGER" $STEAMEXE "" $@ " + + +**To Reproduce** +I downloaded and successfully installed "fex emu armv8.4" from the PPA repository and followed the prompts to install rootfs. However, I encountered an error when attempting to run "steamcmd" in this environment + +**Expected behavior** +I hope to find a solution to this problem, or to create my own rootfs package to solve this problem +**Screenshots and Video** + + + +**System information:** + - OS: [eg: Ubuntu 23.10] + - CPU/SoC: Snapdragon 855 + - RootFS used: [eg: Ubuntu 22.10 Official Rootfs] + - FEX version: (FEXGetConfig --version) [FEX-2312.1] + +**Additional context** + +I am happy to add any details that I have missed + diff --git a/results/scraper/fex/3419 b/results/scraper/fex/3419 new file mode 100644 index 000000000..ad31b2bd7 --- /dev/null +++ b/results/scraper/fex/3419 @@ -0,0 +1,4 @@ +Build system tries to use __attribute__((preserve_all)) on clang 16 +The test program actually compiles on clang 16, because the test function takes 0 arguments and that is apparently not a problem for clang 16 - preserve_all only fails once you add an argument. + +Breaks the build on arm linux, as of this writing. \ No newline at end of file diff --git a/results/scraper/fex/3428 b/results/scraper/fex/3428 new file mode 100644 index 000000000..41a15cf45 --- /dev/null +++ b/results/scraper/fex/3428 @@ -0,0 +1,5 @@ +Tekken 8 slow blocks +The top 11 blocks of code consume 52.27% of the CPU time + + +Adding these hot blocks to instcountci will be good to do. \ No newline at end of file diff --git a/results/scraper/fex/3431 b/results/scraper/fex/3431 new file mode 100644 index 000000000..f35031599 --- /dev/null +++ b/results/scraper/fex/3431 @@ -0,0 +1,4 @@ +GDB stub non-functional due to regression +Merging #3321 regressed the GDB stub functionality: FEXLoader will now crash once gdb connects to it (or gdb itself hangs due to protocol errors). + +To reproduce, run `FEXLoader -G <any x86_64 executable>` and then run the gdb command printed in the console (e.g. `gdb-multiarch -ex "target extended-remote /run/user/1000/FEX_gdbserver/650259-gdb"`). \ No newline at end of file diff --git a/results/scraper/fex/3437 b/results/scraper/fex/3437 new file mode 100644 index 000000000..31f587c66 --- /dev/null +++ b/results/scraper/fex/3437 @@ -0,0 +1,2 @@ +Remove _Neg from IR +Just use sub with an inline constant, easier handling with flags. \ No newline at end of file diff --git a/results/scraper/fex/3444 b/results/scraper/fex/3444 new file mode 100644 index 000000000..a950150ea --- /dev/null +++ b/results/scraper/fex/3444 @@ -0,0 +1,7 @@ +DCE/RCLSE should remove dead register moves +In multiblock + + We should really be able to DCE this move, I guess SRA is getting in the way of regular DCE doing it, so it'd need to be either RCLSE or something like the flag elim pass. @Sonicadvance1 thoughts which is more appropriate? + +_Originally posted by @alyssarosenzweig in https://github.com/FEX-Emu/FEX/pull/3442#discussion_r1498517641_ + \ No newline at end of file diff --git a/results/scraper/fex/3454 b/results/scraper/fex/3454 new file mode 100644 index 000000000..fbed6de4f --- /dev/null +++ b/results/scraper/fex/3454 @@ -0,0 +1 @@ +cmpxchg flags are wrong diff --git a/results/scraper/fex/3455 b/results/scraper/fex/3455 new file mode 100644 index 000000000..c8fafc5d3 --- /dev/null +++ b/results/scraper/fex/3455 @@ -0,0 +1,15 @@ +Vulkan thunks rendering issue with Detroit Become Human. +Tested with Mesa 23.3.6 in both the rootfs and the host. +System: +SoC: NVIDIA Orin +GPU: AMD Radeon Pro W7500 +Driver: RADV 23.3.6 + +Detroit: Become Human has rendering artifacts with thunks enabled but go away with thunks disabled. +Hard to diagnose exactly what the issue is. + +Thunks disabled: + + +Thunks Enabled: + diff --git a/results/scraper/fex/3467 b/results/scraper/fex/3467 new file mode 100644 index 000000000..8fd72c862 --- /dev/null +++ b/results/scraper/fex/3467 @@ -0,0 +1,9 @@ +Optimize rep movs and rep stos +Decent number of games spent a decent amount of time in memcpy and memset. + +Stray's render thread spends 3% in a single block `rep movsb` memcpy. +Metal Gear Rising Revengeance top block is a `rep movsd` for 32-bytes (8 elements). + +`rep movsb` is the one that is worst off since we move byte-by-byte, achieving only 2.7GB/s instead of 17.5GB/s in my microbench. + +Probably want to implement ASIMD and SVE optimized variants in the dispatcher that we can dynamically branch to. For FEAT_MOPS devices we can keep the copy/set inline whenever we implement that. \ No newline at end of file diff --git a/results/scraper/fex/3472 b/results/scraper/fex/3472 new file mode 100644 index 000000000..8d0217280 --- /dev/null +++ b/results/scraper/fex/3472 @@ -0,0 +1,31 @@ +Skyrim SE: Hottest blocks +Skyrim SE's hottest blocks are really hot atomic loop blocks: +1- 6.83% of primary thread +``` +6ffffd37ad33 89f8 mov eax, edi {0x1} +6ffffd37ad35 8706 xchg dword [rsi], eax {0x1} +6ffffd37ad37 85c0 test eax, eax +6ffffd37ad39 7555 jne 0x6ffffd37ad90 +``` + +2- 5.12% of primary thread +``` +6ffffd4a8300 488d410c lea rax, [rcx+0xc] +6ffffd4a8304 f0ff08 lock dec dword [rax] +6ffffd4a8307 7407 je 0x6ffffd4a8310 +``` + +3- 5.03% of primary thread +``` +6ffffd4405f7 lea rax, [rcx+0xc] +6ffffd4405fb lock dec dword [rax] +6ffffd4405fe jne 0x6ffffd44060d +``` +lock dec at the very least can optimize away a mov+neg combination in to a mov. Looking at instcountci. +https://github.com/FEX-Emu/FEX/blob/d24446ed139b6740d5e606ddc05b7028b5fecaf8/unittests/InstructionCountCI/FlagM/Atomics.json#L1412 + + +These three blocks are totaling 16.98% of CPU time on the primary thread on Cortex-A78AE. All coming from d3d11.dll in DXVK. + +4- 2.7% - RIP: 0x1414df7c7 - SkyrimSE.exe +- Encrypted EXE, needs investigation diff --git a/results/scraper/fex/3476 b/results/scraper/fex/3476 new file mode 100644 index 000000000..94198b897 --- /dev/null +++ b/results/scraper/fex/3476 @@ -0,0 +1,6 @@ +Need to update Vulkan Headers for thunks. +Newer Vulkan drivers (like Mesa 24.0) ships a newer version of Vulkan than what our thunks supports. This causes DXVK to use features that our thunks don't support and results in games having early initialization failure. + +We currently ship: v1.3.261 +Mesa radv ships as of writing: 1.3.274 +Current header version as of writing: 1.3.278 \ No newline at end of file diff --git a/results/scraper/fex/3479 b/results/scraper/fex/3479 new file mode 100644 index 000000000..7f2a5d78c --- /dev/null +++ b/results/scraper/fex/3479 @@ -0,0 +1,11 @@ +Newest Steam update (Feb 29 2024) fails to launch steamwebhelper +Tested with commits 0ef72bf11 (previously working) and 9ae55ff + +Steam simply logs: + +``` +steamwebhelper.sh[6094]: Starting steamwebhelper under bootstrap sniper steam runtime at /home/cmcging/.local/share/Steam/ubuntu12_64/steam-runtime-sniper +``` +and tries to restart it once a minute or so. The "steamwebhelper, a critical Steam component, is not responding." dialog appears as well. + +System: Ubuntu 23.10 on Pi 5 \ No newline at end of file diff --git a/results/scraper/fex/348 b/results/scraper/fex/348 new file mode 100644 index 000000000..98fa6f926 --- /dev/null +++ b/results/scraper/fex/348 @@ -0,0 +1,3 @@ +Config files need to be more robust +Now that we supprot binfmt_misc, config files need to stop blowing away various options. +Time to implement a overlay configuration system \ No newline at end of file diff --git a/results/scraper/fex/3481 b/results/scraper/fex/3481 new file mode 100644 index 000000000..43eaccf5a --- /dev/null +++ b/results/scraper/fex/3481 @@ -0,0 +1,10 @@ +VVVVVV crashes with Vulkan+GL thunks enabled +The game crashes early with a SIGSEGV when vulkan and GL thunks are enabled. GL alone might work but it seemingly blackscreens? + +Anyway, the SIGSEGV occurs because it uses xcb to try and get the PULSE_COOKIE x11 window property, which it gets but then fails to parse (Bad data returned?). + +GL alone doesn't trigger the crash since xcb thunking is disabled in that case. + +The game crashes because not getting the pulse cookie is fatal and it fails to setup some sound samples, it then continues to try and load a pointer that was never allocated. + +Problem should go away once we rewrite how the X11/xcb communication occurs? \ No newline at end of file diff --git a/results/scraper/fex/3496 b/results/scraper/fex/3496 new file mode 100644 index 000000000..7ba233ad9 --- /dev/null +++ b/results/scraper/fex/3496 @@ -0,0 +1,11 @@ +Unsupported system page size segfault +**The Bug** +When I run the FEXBash command at all, it just outputs this +\<jemalloc>: Unsupported system page size +\<jemalloc>: Unsupported system page size +zsh: segmentation fault (core dumped) FEXBash + +**What machine I'm on** +OS: Fedora Linux Asahi Remix 39 (Thirty Nine) aarch64 +Host: Apple MacBook Air (M1, 2020) +Kernel: 6.6.3-413.asahi.fc39.aarch64+16k diff --git a/results/scraper/fex/3498 b/results/scraper/fex/3498 new file mode 100644 index 000000000..4228d6e88 --- /dev/null +++ b/results/scraper/fex/3498 @@ -0,0 +1,34 @@ +Memcpy optimization crashing Sonic Mania movie player +https://github.com/FEX-Emu/FEX/blob/7dcacfe9909488365035fff2606db20c363d1576/FEXCore/Source/Interface/Core/JIT/Arm64/MemoryOps.cpp#L2149 + +This inner loop is causing Sonic Mania to crash for some reason. It's seemingly not crashing in the memcpy implementation itself but somewhere else because of this. + +To reproduce: +- Run Sonic Mania +- Wait on the title screen for the attract movie to start playing +- See it crash before the `1,2,3,K` elevator symbols appear on screen. + +Current testing: +- It's memcpy specifically, but the same bug likely exists in the memset since the implementations are similar. +- It's specifically the forward direction memcpy and not in the inline path + - Tested by dropping the old implementation in and bisecting the code paths + +The crash appears from the code doing an indirect fetch and then dereferencing a nullptr. This happens at RIP block `0x5fa25d` inside of SonicMania.exe but since the executable is obfuscated it's a bit harder to see what that code block is. + +```asm + 0x005fa25d: mov ecx,0x20 + 0x005fa262: sub ecx,edi + 0x005fa264: shr eax,cl + 0x005fa266: mov ebx,DWORD PTR [ebx+eax*4+0x4] + 0x005fa26a: movzx ecx,BYTE PTR [ebx+0x2] ; <---- This instruction specifically. ebx is zero. + 0x005fa26e: shl DWORD PTR [esi],cl + 0x005fa270: sub DWORD PTR [esi+0xc],ecx + 0x005fa273: mov al,BYTE PTR [ebx] + 0x005fa275: test al,al + 0x005fa277: jne 0x5fa240 + 0x005fa279: pop edi + 0x005fa27a: movzx eax,BYTE PTR [ebx+0x1] + 0x005fa27e: pop esi + 0x005fa27f: pop ebx + 0x005fa280: ret + ``` diff --git a/results/scraper/fex/351 b/results/scraper/fex/351 new file mode 100644 index 000000000..225b5d375 --- /dev/null +++ b/results/scraper/fex/351 @@ -0,0 +1,2 @@ +Zext semantics are broken +Eliminating supposedly harmless full-extract BFEs breaks CS:GO's shader translation logic \ No newline at end of file diff --git a/results/scraper/fex/3516 b/results/scraper/fex/3516 new file mode 100644 index 000000000..53a305d85 --- /dev/null +++ b/results/scraper/fex/3516 @@ -0,0 +1,31 @@ +Deal with branchy instructions +We'd like to move towards an IR with purely local liveness. This requires reworking the dispatcher for any opcode that translates to multiple blocks. This ticket tracks the audit of all such opcodes. + +These opcodes need logic changes: + +- [x] daa (#3514 ) +- [x] das (#3514 ) +- [x] aaa (#3514 ) +- [x] aad (#3514 ) +- [x] rep cmps (#3542) +- [x] rep lods (#3542) +- [x] rep scas (#3542) +- [x] cmpxchg pair (#3522 ) +- [x] shift left (#3548) +- [x] shift right (#3548) +- [x] signed shift left (#3548) +- [x] rotate right (#3539) +- [x] rotate left (#3539 ) +- [x] rcr (#3536) +- [x] rcr smaller (#3536) +- [x] rcl (#3536) +- [x] rcl smaller (#3536) +- [x] XSave (#3528 ) +- [x] XRstor (#3528 ) +- [x] self modifying code (#3550) + +These I've audited to be ok + +* int +* jumps +* undefined \ No newline at end of file diff --git a/results/scraper/fex/3519 b/results/scraper/fex/3519 new file mode 100644 index 000000000..7e44f0fa0 --- /dev/null +++ b/results/scraper/fex/3519 @@ -0,0 +1,33 @@ +Sekiro under Proton crashes with thunks +Sekiro when running under Proton crashes if thunks are enabled. For some reason it gets a nullptr dereference in vkCreateInstance because the pointer is null. + +With a hack I can get it to work: +```diff +diff --git a/ThunkLibs/libvulkan/Host.cpp b/ThunkLibs/libvulkan/Host.cpp +index 1cfaa4227..de5cf2ec9 100644 +--- a/ThunkLibs/libvulkan/Host.cpp ++++ b/ThunkLibs/libvulkan/Host.cpp +@@ -77,6 +77,10 @@ static VkResult FEXFN_IMPL(vkCreateInstance)(const VkInstanceCreateInfo* a_0, co + } + } + ++ if (LDR_PTR(vkCreateInstance) == nullptr) [[unlikely]] { ++ (void*&)LDR_PTR(vkCreateInstance) = (void*)dlsym_default(fexldr_ptr_libvulkan_so, "vkCreateInstance"); ++ } ++ + VkInstance out; + auto ret = LDR_PTR(vkCreateInstance)(vk_struct_base, nullptr, &out); + if (ret == VK_SUCCESS) { + ``` + +Weirdly, the other symbols loaded with `DoSetupWithInstance` are populated +``` +(gdb) p/x fexldr_ptr_libvulkan_vkCreateInstance +$1 = 0x0 +(gdb) p/x fexldr_ptr_libvulkan_vkCreateDevice +$2 = 0x7fffc6f9f990 +(gdb) p/x fexldr_ptr_libvulkan_vkGetDeviceProcAddr +$3 = 0x7fffc6f9e1a0 +``` + +This should be investigated, I'm not sure how many games are hitting this issue. \ No newline at end of file diff --git a/results/scraper/fex/3523 b/results/scraper/fex/3523 new file mode 100644 index 000000000..f53bdbbea --- /dev/null +++ b/results/scraper/fex/3523 @@ -0,0 +1,19 @@ +Investigate 20020224-1.c.gcc-target-test-64.jit.gcc-target-64 +This thing keeps flaking in CI in the glibc allocation fault test, see wtf it is doing. + +List of tests flaking in glibc fault test: +- 20020224-1.c.gcc-target-test-64.jit.gcc-target-64 + - Happened on mac-mini-1 - 3 times. + - Happened on mac-mini-2 - 2 times. +- 20000614-1.c.gcc-target-test-64 + - Happened on mac-mini-1 - 3 times + - Happened on mac-mini-2 - 2 times + - Happened on orin-3 - 1 time +- 20011009-1.c.gcc-target-test-64 + - Happened on mac-mini-1 - 3 times + - Happened on mac-mini-2 - 3 times +- 20000614-2.c.gcc-target-test-64 + - Happened on mac-mini-1 - 4 times + - Happened on mac-mini-2 - 4 times + +This might be a runner specific problem happening before we have full allocator control. diff --git a/results/scraper/fex/3524 b/results/scraper/fex/3524 new file mode 100644 index 000000000..f00beb650 --- /dev/null +++ b/results/scraper/fex/3524 @@ -0,0 +1,12 @@ +Support partial JIT invalidation +LÖVE 11.5 game engine has switched over to using LuaJIT by default. This causes [Balatro](https://store.steampowered.com/app/2379780/Balatro/) to /constantly/ JIT code through code invalidations. + +This is due to how LuaJIT compiles, it allocates 128KB at the start, and each time it generates new JIT code it changes permission of the code segment to RW for the full range, JITs code by appending to the end, and then changes back to RX. This causes FEX to invalidate all code in that mapping and spend all CPU time JITTing the same code over and over. This drops the game to sub 1FPS. + +If we recognize that a region is a JIT region and do partial invalidations this will significantly improve the situation. +We could do this by: +- hashing a JIT region code upfront (xxhash likely) +- On invalidation just remove jump entries +- On JIT, just do a lookup and hash check to put the entry back in JIT + +This will have a bit of stampeding in the JIT after each invalidation, but better than full reJIT. \ No newline at end of file diff --git a/results/scraper/fex/3554 b/results/scraper/fex/3554 new file mode 100644 index 000000000..af485cce6 --- /dev/null +++ b/results/scraper/fex/3554 @@ -0,0 +1,78 @@ +amogus crashes if started through steam +**What Game** +[amogus](https://store.steampowered.com/app/945360/Among_Us/) + +**Describe the bug** +The game doesn't start (crashes after Innersloth logo fades out) if started through Steam. If the game is started directly (`proton .steam/steam/steamapps/common/Among\ Us/Among\ Us.exe` or similar) with steam NOT running, it starts up just fine, though without Steamworks access. + +**To Reproduce** +Steps to reproduce the behavior: +1. Open amogus through steam (library / through a gameid link) +2. It crashes (sus) +3. Open amogus directly +4. It doesn't crash + +**Expected behavior** +No crashes involved + +**System information:** + - OS: Ubuntu 23.10 arm64 + - CPU/SoC: Qualcomm SC8280XP on Lenovo ThinkPad X13s + - Video driver version: Mesa 23.2.1-1ubuntu3.1 + - RootFS used: Ubuntu 23.10 Official Rootfs + - FEX version: (FEXGetConfig --version): FEX-2403-184-g202a60b + - Thunks Enabled: No (I believe) + +**Additional context** + - Is this an x86 or x86-64 game: x86 (I believe) + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: No (I believe) + +Steam API usage: +``` +Game 945360 created interface STEAMAPPLIST_INTERFACE_VERSION001 / AppList +Game 945360 created interface STEAMAPPS_INTERFACE_VERSION008 / Apps +Game 945360 created interface STEAMHTMLSURFACE_INTERFACE_VERSION_005 / HTMLSurface +Game 945360 created interface STEAMHTTP_INTERFACE_VERSION003 / HTTP +Game 945360 created interface STEAMINVENTORY_INTERFACE_V003 / Inventory +Game 945360 created interface STEAMMUSICREMOTE_INTERFACE_VERSION001 / MusicRemote +Game 945360 created interface STEAMMUSIC_INTERFACE_VERSION001 / Music +Game 945360 created interface STEAMPARENTALSETTINGS_INTERFACE_VERSION001 / ParentalSettings +Game 945360 created interface STEAMREMOTEPLAY_INTERFACE_VERSION001 / RemotePlay +Game 945360 created interface STEAMREMOTESTORAGE_INTERFACE_VERSION014 / RemoteStorage +Game 945360 created interface STEAMSCREENSHOTS_INTERFACE_VERSION003 / Screenshots +Game 945360 created interface STEAMUGC_INTERFACE_VERSION015 / UGC +Game 945360 created interface STEAMUSERSTATS_INTERFACE_VERSION012 / UserStats +Game 945360 created interface STEAMVIDEO_INTERFACE_V002 / Video +Game 945360 created interface SteamController008 / +Game 945360 created interface SteamFriends017 / Friends +Game 945360 created interface SteamInput002 / +Game 945360 created interface SteamInput002 / Controller +Game 945360 created interface SteamMatchGameSearch001 / GameSearch +Game 945360 created interface SteamMatchMaking009 / Matchmaking +Game 945360 created interface SteamMatchMakingServers002 / MatchmakingServers +Game 945360 created interface SteamNetworking006 / Networking +Game 945360 created interface SteamNetworkingMessages002 / +Game 945360 created interface SteamNetworkingSockets009 / +Game 945360 created interface SteamNetworkingUtils003 / +Game 945360 created interface SteamParties002 / Parties +Game 945360 created interface SteamUser021 / User +Game 945360 created interface SteamUtils010 / +Game 945360 created interface SteamUtils010 / Utils +Game 945360 method call count for IClientNetworkingSocketsSerialized::GetSTUNServer : 2 +Game 945360 method call count for IClientNetworkingSocketsSerialized::GetCachedRelayTicketCount : 1 +Game 945360 method call count for IClientNetworkingSocketsSerialized::GetCertAsync : 1 +Game 945360 method call count for IClientHTTP::ReleaseHTTPRequest : 2 +Game 945360 method call count for IClientHTTP::GetHTTPResponseBodyData : 2 +Game 945360 method call count for IClientHTTP::SendHTTPRequest : 2 +Game 945360 method call count for IClientHTTP::SetHTTPRequestHeaderValue : 1 +Game 945360 method call count for IClientHTTP::CreateHTTPRequest : 2 +Game 945360 method call count for IClientAppManager::GetCurrentLanguage : 1 +Game 945360 method call count for IClientUtils::RecordSteamInterfaceCreation : 32 +Game 945360 method call count for IClientUtils::GetAPICallResult : 6 +Game 945360 method call count for IClientUtils::GetAppID : 35 +Game 945360 method call count for IClientUtils::GetIPCountry : 1 +Game 945360 method call count for IClientUser::GetSteamID : 2 +Game 945360 method call count for IClientUser::BLoggedOn : 1 +Uploaded AppInterfaceStats to Steam +``` \ No newline at end of file diff --git a/results/scraper/fex/356 b/results/scraper/fex/356 new file mode 100644 index 000000000..c9d992edf --- /dev/null +++ b/results/scraper/fex/356 @@ -0,0 +1,7 @@ +Switch thunk generator to use FindPythonInterp +https://cmake.org/cmake/help/v3.0/module/FindPythonInterp.html + + +Change these lines to use the executable returned by this function, or early exit out. +https://github.com/FEX-Emu/FEX/blob/master/ThunkLibs/GuestLibs/CMakeLists.txt#L21 +https://github.com/FEX-Emu/FEX/blob/master/ThunkLibs/HostLibs/CMakeLists.txt#L14 \ No newline at end of file diff --git a/results/scraper/fex/3565 b/results/scraper/fex/3565 new file mode 100644 index 000000000..8acb2bb76 --- /dev/null +++ b/results/scraper/fex/3565 @@ -0,0 +1,3 @@ +2K Launcher is broken under FEX +After it installs the vc runtimes and updates itself it just closes. Needs an investigation. +Just run any bioshock game or Civ 6 to see the problem. \ No newline at end of file diff --git a/results/scraper/fex/357 b/results/scraper/fex/357 new file mode 100644 index 000000000..97ba02e7d --- /dev/null +++ b/results/scraper/fex/357 @@ -0,0 +1,9 @@ +Ensure thunk generator generates "gen" folder +Currently the thunk generator fails if the gen folder isn't generated +https://github.com/FEX-Emu/FEX/blob/master/ThunkLibs/GuestLibs/CMakeLists.txt#L13 +https://github.com/FEX-Emu/FEX/blob/master/ThunkLibs/HostLibs/CMakeLists.txt#L6 + +Ensure this folder is created as part of the build script. + +For an example for elsewhere creating the directory. +https://github.com/FEX-Emu/FEX/blob/955bdf296484827f6f8f67959dcbd51314eb8c37/unittests/ASM/CMakeLists.txt#L15 \ No newline at end of file diff --git a/results/scraper/fex/3590 b/results/scraper/fex/3590 new file mode 100644 index 000000000..b756b4fcc --- /dev/null +++ b/results/scraper/fex/3590 @@ -0,0 +1,2 @@ +Ubisoft Connect requires EFLAGS.TF support +What a nightmare. \ No newline at end of file diff --git a/results/scraper/fex/3593 b/results/scraper/fex/3593 new file mode 100644 index 000000000..f09c4d96e --- /dev/null +++ b/results/scraper/fex/3593 @@ -0,0 +1,47 @@ +[static] SIGSEGV when run /usr/bin/FEXInterpreter compile with static +[root@localhost ~]# ldd /usr/bin/FEXInterpreter + not a dynamic executable + +====== link flags: + LINK_FLAGS = -Wl,--export-dynamic -rdynamic -fuse-ld=lld -fPIE -pie #dynamic + + LINK_FLAGS = -static -fuse-ld=lld -fPIE # static + +===== core trace: +(gdb) info locals +Current = 0xffffd2b7ca30 +MapBase = 281474217003728 +MapTop = 281474217003552 +OffsetDiff = 9667160 +Top = 4988928 +CurrentIter = {_M_node = 0xffff7f8290c0} +(gdb) frame 1 +#1 0x00000000009368b8 in std::_Rb_tree_iterator<std::pair<unsigned long const, FEX::HLE::SyscallHandler::VMAEntry> >::operator-- (this=0xffffd2b7ca28) + at /opt/rh/gcc-toolset-13/root/usr/lib/gcc/aarch64-redhat-linux/13/../../../../include/c++/13/bits/stl_tree.h:310 +310 _M_node = _Rb_tree_decrement(_M_node); +(gdb) info locals +__tmp = {_M_node = 0xffff7f8290c0} +(gdb) bt +#0 0x00000000004c08e0 in std::_Rb_tree_decrement(std::_Rb_tree_node_base*) () +#1 0x00000000009368b8 in std::_Rb_tree_iterator<std::pair<unsigned long const, FEX::HLE::SyscallHandler::VMAEntry> >::operator-- (this=0xffffd2b7ca28) + at /opt/rh/gcc-toolset-13/root/usr/lib/gcc/aarch64-redhat-linux/13/../../../../include/c++/13/bits/stl_tree.h:310 +#2 0x000000000093b600 in FEX::HLE::SyscallHandler::VMATracking::ClearUnsafe (this=0xffff7f87d5a8, + CTX=0xffff7f850000, Base=4968448, Length=20480, PreservedMappedResource=0x0) + at ../Source/Tools/LinuxEmulation/LinuxSyscalls/SyscallsVMATracking.cpp:172 +#3 0x000000000093b4a8 in FEX::HLE::SyscallHandler::VMATracking::SetUnsafe (this=0xffff7f87d5a8, + CTX=0xffff7f850000, MappedResource=0x0, Base=4968448, Offset=0, Length=20480, Flags=..., Prot=...) + at ../Source/Tools/LinuxEmulation/LinuxSyscalls/SyscallsVMATracking.cpp:147 +#4 0x0000000000936e2c in FEX::HLE::SyscallHandler::TrackMmap (this=0xffff7f87d000, Thread=0x0, + Base=4968448, Size=20480, Prot=3, Flags=2098, fd=-1, Offset=0) + at ../Source/Tools/LinuxEmulation/LinuxSyscalls/SyscallsSMCTracking.cpp:230 +#5 0x00000000009752cc in FEX::HLE::x64::x64SyscallHandler::GuestMmap (this=0xffff7f87d000, + Thread=0x0, addr=0x4bd000 <std::__time_get_state::_M_finalize_state(tm*)+320>, length=20480, + prot=3, flags=2098, fd=-1, offset=0) + at ../Source/Tools/LinuxEmulation/LinuxSyscalls/x64/Memory.cpp:41 +#6 0x000000000062fa68 in ELFCodeLoader::LoadElfFile (this=0xffffd2b7f4b8, Elf=..., + BrkBase=0xffffd2b7e028, Handler=0xffff7f87d000, LoadHint=0) + at ../Source/Tools/FEXLoader/ELFCodeLoader.h:158 +#7 0x0000000000621b54 in ELFCodeLoader::MapMemory (this=0xffffd2b7f4b8, Handler=0xffff7f87d000) + at ../Source/Tools/FEXLoader/ELFCodeLoader.h:531 +#8 0x000000000061f628 in main (argc=3, argv=0xffffd2b813c8, envp=0xffffd2b813e8) + at ../Source/Tools/FEXLoader/FEXLoader.cpp:480 \ No newline at end of file diff --git a/results/scraper/fex/3611 b/results/scraper/fex/3611 new file mode 100644 index 000000000..044a74087 --- /dev/null +++ b/results/scraper/fex/3611 @@ -0,0 +1,10 @@ +Steam streaming now crashes with an assert +This used to work but it seems something changed on Steam's side that broke this. When streaming a game from some other system to the Arm64 system then Steam will SIGABRT with the following log message. +``` +terminate called after throwing an instance of 'std::logic_error' + what(): basic_string::_S_construct null not valid +``` + +Interestingly this doesn't affect streaming from an arm64 device to some other device. Seems to only be a decoder issue rather than an encoder issue. + +Changing decoder settings to use hardware decoding doesn't change behaviour. Needs some investigation. \ No newline at end of file diff --git a/results/scraper/fex/3619 b/results/scraper/fex/3619 new file mode 100644 index 000000000..f2231a8f4 --- /dev/null +++ b/results/scraper/fex/3619 @@ -0,0 +1,4 @@ +Need a unique_ptr implementation that is standard layout to remove warnings from project +Brought up by #3618 + +Ideally anything using default deleter or whatever decomposes down to only 8-bytes like libstdc++'s std::unique_ptr \ No newline at end of file diff --git a/results/scraper/fex/3623 b/results/scraper/fex/3623 new file mode 100644 index 000000000..aded84df7 --- /dev/null +++ b/results/scraper/fex/3623 @@ -0,0 +1,7 @@ +Current X87 issues +This is just my list of the things I know are problematic but since they are fixed in my branch, I haven't patched upstream yet. + +1. <del>Subtract and division has reverse operators incorrectly set: See https://github.com/FEX-Emu/FEX/pull/3547/commits/efa09a1f9b99f4323e7d280eb530bc1bac6fdcc5</del> +2. fst st(i) is not setting tag properly: See test https://github.com/FEX-Emu/FEX/blob/f15b7b0941d15655b3704122960e063490625259/unittests/ASM/X87/DD_D0_2.asm which fails with current upstream. +3. FXCH should set C1 to Zero: See https://github.com/FEX-Emu/FEX/pull/3547/commits/361fbcf93abdef1a40f1a6046acabec3f2b3775c +4. <del>There's some issue with top off by one in 64bits. D9_F7_F64.asm, RAX should end up with 0x4070000000000000 per my understanding. cc: @CallumDev </del> \ No newline at end of file diff --git a/results/scraper/fex/3631 b/results/scraper/fex/3631 new file mode 100644 index 000000000..3b1ddc182 --- /dev/null +++ b/results/scraper/fex/3631 @@ -0,0 +1,4 @@ +Blocks are not physically removed +I haven't looked into the algo in detail but it feels to me like we should not ignore the return value of `std::remove`. This does not physically remove the Predecessor, simply moves it to another place. We should probably use `std::erase` here. See https://en.wikipedia.org/wiki/Erase%E2%80%93remove_idiom + +https://github.com/FEX-Emu/FEX/blame/c5f8ea58e91df8ad73a8efb6ae2b0206662ea24c/FEXCore/Source/Interface/IR/Passes/RAValidation.cpp#L246 \ No newline at end of file diff --git a/results/scraper/fex/364 b/results/scraper/fex/364 new file mode 100644 index 000000000..9bffd2222 --- /dev/null +++ b/results/scraper/fex/364 @@ -0,0 +1,8 @@ +Some posix tests are race happy +Loads of tests do some sleeping or forking and sleeping. +Which this results is buggy racing. +We need special handling of these to stop them randomly breaking +Probably serializing the tests and maybe a small retry loop. + +difftime-1-1 was one that I just saw as being a race. +Bunch of random signal tests are also race happy. \ No newline at end of file diff --git a/results/scraper/fex/3653 b/results/scraper/fex/3653 new file mode 100644 index 000000000..ba1681ec1 --- /dev/null +++ b/results/scraper/fex/3653 @@ -0,0 +1,16 @@ +LoadConstant should better handle negatives +FEX: + +```asm + mov x20, #0xc299 + movk x20, #0x8646, lsl #16 + movk x20, #0xffff, lsl #32 + movk x20, #0xffff, lsl #48 +``` + +clang: + +```asm + mov x8, #0xffffffffffffc299 // #-15719 + movk x8, #0x8646, lsl #16 +``` \ No newline at end of file diff --git a/results/scraper/fex/3657 b/results/scraper/fex/3657 new file mode 100644 index 000000000..be52587d3 --- /dev/null +++ b/results/scraper/fex/3657 @@ -0,0 +1,27 @@ +Redundant context loads when distinct pshufd's in a block +bytemark has a sequence like: + +``` + "pshufd xmm2,xmm3,0xf5", + "addpd xmm1,xmm12", + "pmuludq xmm3,xmm9", + "pshufd xmm3,xmm3,0xe8", +``` + +because the pshufd indices differ, we can't cache the constant. and we end up generating code + +``` + "ldr x0, [x28, #1760]", + "ldr q3, [x0, #3920]", + "tbl v18.16b, {v19.16b}, v3.16b", + "fadd v17.2d, v17.2d, v28.2d", + "uzp1 v4.4s, v19.4s, v19.4s", + "uzp1 v5.4s, v25.4s, v25.4s", + "umull v19.2d, v4.2s, v5.2s", + "ldr x0, [x28, #1760]", + "ldr q4, [x0, #3712]", + "tbl v19.16b, {v19.16b}, v4.16b", +``` + +Notice that we reload the base vector addresses in the same block, instead of caching it. At minimum we should probably fix that. But I'm also questioning if there's maybe a better way to do pshufd? Not sure + diff --git a/results/scraper/fex/3659 b/results/scraper/fex/3659 new file mode 100644 index 000000000..da3b96466 --- /dev/null +++ b/results/scraper/fex/3659 @@ -0,0 +1,272 @@ +Documenting difference between AVX2 gather loadstores before they're implemented +Some prototyping of AVX2 gather loadstores in CPP just to show how ugly it is between SVE-256 and SVE-128 before FEX-Emu has implemented it. + +<details> +<summary>CPP</summary> + +```cpp +#include <cstddef> +#include <cstdint> +#include <cstring> +#include <type_traits> + +#ifdef __aarch64__ +// Compile with `-O3 -march=armv8-a+sve -msve-vector-bits=128` +// Or +// Compile with `-O3 -march=armv8-a+sve -msve-vector-bits=256` +// To see the difference +#include <arm_neon.h> +#include <arm_sve.h> + +struct ContextObject { + uint8_t Pad[512]; + // Maximum uint64_t times 4 times for gather loadstores. + uint8_t TempSpace[32]; +}; + +#if __ARM_FEATURE_SVE_BITS != 128 +using Vec256 = svuint64_t; + +template<typename IndexType, size_t Scale> +Vec256 GatherLoad_ArbitraryScale( + ContextObject *Ctx, + svbool_t pg_256bit, + uint64_t *base, + Vec256 indices) { + using IndexTypeScaled = typename std::conditional<std::is_signed_v<IndexType>, int64_t, uint64_t>::type; + IndexType *Indexes = (IndexType*)Ctx->TempSpace; + svst1_u64(pg_256bit, Indexes, indices); + for (size_t i = 0; i < 4; ++i) { + IndexTypeScaled Index = Indexes[i]; + uint64_t *Addr = (uint64_t*)((uint64_t)base + (Index << Scale)); + Indexes[i] = *Addr; + } + + return svld1(pg_256bit, Indexes); +} + +Vec256 GatherLoad1_u64(ContextObject *Ctx, svbool_t pg_256bit, uint64_t *base, Vec256 indices) { + return svld1_gather_u64offset_u64(pg_256bit, base, indices); +} +Vec256 GatherLoad2_u64(ContextObject *Ctx, svbool_t pg_256bit, uint64_t *base, Vec256 indices) { + return GatherLoad_ArbitraryScale<uint64_t, 2>(Ctx, pg_256bit, base, indices); +} +Vec256 GatherLoad4_u64(ContextObject *Ctx, svbool_t pg_256bit, uint64_t *base, Vec256 indices) { + return GatherLoad_ArbitraryScale<uint64_t, 4>(Ctx, pg_256bit, base, indices); +} +Vec256 GatherLoad8_u64(ContextObject *Ctx, svbool_t pg_256bit, uint64_t *base, Vec256 indices) { + return svld1_gather_u64index_u64(pg_256bit, base, indices); +} +#elif __ARM_FEATURE_SVE_BITS == 128 +struct Vec256 { + uint64x2_t Lower; + uint64x2_t Upper; +}; + +template<typename IndexType, size_t Scale> +Vec256 GatherLoad_ArbitraryScale( + ContextObject *Ctx, + svbool_t pg_256bit, + uint64_t *base, + Vec256 indices) { + using IndexTypeScaled = typename std::conditional<std::is_signed_v<IndexType>, int64_t, uint64_t>::type; + IndexType *Indexes = (IndexType*)Ctx->TempSpace; + memcpy(Indexes, &indices, sizeof(Vec256)); + for (size_t i = 0; i < 4; ++i) { + IndexTypeScaled Index = Indexes[i]; + uint64_t *Addr = (uint64_t*)((uint64_t)base + (Index << Scale)); + Indexes[i] = *Addr; + } + + Vec256 Result{}; + memcpy(&Result, Indexes, sizeof(Vec256)); + return Result; +} + +Vec256 GatherLoad1_u64( + ContextObject *Ctx, + svbool_t pg_128bit, + uint64_t *base, + svuint64_t indices_lower, + svuint64_t indices_upper) { + Vec256 Result{}; + uint64_t *Indexes = (uint64_t*)Ctx->TempSpace; + auto Lower = svld1_gather_u64offset_u64(pg_128bit, base, indices_lower); + auto Upper = svld1_gather_u64offset_u64(pg_128bit, base, indices_upper); + svst1_u64(pg_128bit, Indexes, Lower); + svst1_u64(pg_128bit, &Indexes[4], Upper); + memcpy(&Result, Indexes, sizeof(Vec256)); + return Result; +} +Vec256 GatherLoad2_u64(ContextObject *Ctx, svbool_t pg_256bit, uint64_t *base, Vec256 indices) { + return GatherLoad_ArbitraryScale<uint64_t, 2>(Ctx, pg_256bit, base, indices); +} +Vec256 GatherLoad4_u64(ContextObject *Ctx, svbool_t pg_256bit, uint64_t *base, Vec256 indices) { + return GatherLoad_ArbitraryScale<uint64_t, 4>(Ctx, pg_256bit, base, indices); +} +Vec256 GatherLoad8_u64( ContextObject *Ctx, + svbool_t pg_128bit, + uint64_t *base, + svuint64_t indices_lower, + svuint64_t indices_upper) { + Vec256 Result{}; + uint64_t *Indexes = (uint64_t*)Ctx->TempSpace; + auto Lower = svld1_gather_u64index_u64(pg_128bit, base, indices_lower); + auto Upper = svld1_gather_u64index_u64(pg_128bit, base, indices_upper); + svst1_u64(pg_128bit, Indexes, Lower); + svst1_u64(pg_128bit, &Indexes[4], Upper); + memcpy(&Result, Indexes, sizeof(Vec256)); + return Result;} +#else +#error unsupported +#endif + +#else +#include <immintrin.h> +// Not quite matching since this is doing an insert and mask which FEX needs to handle +using Vec256 = __m256i; +Vec256 GatherLoad1(uint64_t *base, Vec256 indices) { + return _mm256_i64gather_epi64 (base, indices, 1); +} +Vec256 GatherLoad2(uint64_t *base, Vec256 indices) { + return _mm256_i64gather_epi64 (base, indices, 2); +} +Vec256 GatherLoad4(uint64_t *base, Vec256 indices) { + return _mm256_i64gather_epi64 (base, indices, 4); +} +Vec256 GatherLoad8(uint64_t *base, Vec256 indices) { + return _mm256_i64gather_epi64 (base, indices, 8); +} +#endif +``` + +</details> +<details> + <summary>Assembly SVE-128bit</summary> + +```asm +GatherLoad1_u64(ContextObject*, __SVBool_t, unsigned long*, __SVUint64_t, __SVUint64_t): // @GatherLoad1_u64(ContextObject*, __SVBool_t, unsigned long*, __SVUint64_t, __SVUint64_t) + ld1d { z0.d }, p0/z, [x1, z0.d] + mov x8, #64 // =0x40 + mov x9, #68 // =0x44 + ld1d { z1.d }, p0/z, [x1, z1.d] + st1d { z0.d }, p0, [x0, x8, lsl #3] + st1d { z1.d }, p0, [x0, x9, lsl #3] + ldp q0, q1, [x0, #512] + ret +GatherLoad2_u64(ContextObject*, __SVBool_t, unsigned long*, Vec256): // @GatherLoad2_u64(ContextObject*, __SVBool_t, unsigned long*, Vec256) + fmov x9, d0 + mov x8, v0.d[1] + stp q0, q1, [x0, #512] + fmov x10, d1 + lsl x9, x9, #2 + lsl x8, x8, #2 + lsl x10, x10, #2 + ldr x9, [x9, x1] + str x9, [x0, #512] + mov x9, v1.d[1] + ldr x8, [x8, x1] + str x8, [x0, #520] + ldr x8, [x10, x1] + lsl x9, x9, #2 + str x8, [x0, #528] + ldr x8, [x9, x1] + str x8, [x0, #536] + ldp q0, q1, [x0, #512] + ret +GatherLoad4_u64(ContextObject*, __SVBool_t, unsigned long*, Vec256): // @GatherLoad4_u64(ContextObject*, __SVBool_t, unsigned long*, Vec256) + fmov x9, d0 + mov x8, v0.d[1] + stp q0, q1, [x0, #512] + fmov x10, d1 + lsl x9, x9, #4 + lsl x8, x8, #4 + lsl x10, x10, #4 + ldr x9, [x9, x1] + str x9, [x0, #512] + mov x9, v1.d[1] + ldr x8, [x8, x1] + str x8, [x0, #520] + ldr x8, [x10, x1] + lsl x9, x9, #4 + str x8, [x0, #528] + ldr x8, [x9, x1] + str x8, [x0, #536] + ldp q0, q1, [x0, #512] + ret +GatherLoad8_u64(ContextObject*, __SVBool_t, unsigned long*, __SVUint64_t, __SVUint64_t): // @GatherLoad8_u64(ContextObject*, __SVBool_t, unsigned long*, __SVUint64_t, __SVUint64_t) + ld1d { z0.d }, p0/z, [x1, z0.d, lsl #3] + mov x8, #64 // =0x40 + mov x9, #68 // =0x44 + ld1d { z1.d }, p0/z, [x1, z1.d, lsl #3] + st1d { z0.d }, p0, [x0, x8, lsl #3] + st1d { z1.d }, p0, [x0, x9, lsl #3] + ldp q0, q1, [x0, #512] + ret +``` + +</details> +<details> + <summary>Assembly SVE-256bit</summary> + +```asm +GatherLoad1_u64(ContextObject*, __SVBool_t, unsigned long*, __SVUint64_t): // @GatherLoad1_u64(ContextObject*, __SVBool_t, unsigned long*, __SVUint64_t) + ld1d { z0.d }, p0/z, [x1, z0.d] + ret +GatherLoad2_u64(ContextObject*, __SVBool_t, unsigned long*, __SVUint64_t): // @GatherLoad2_u64(ContextObject*, __SVBool_t, unsigned long*, __SVUint64_t) + mov x8, #64 // =0x40 + st1d { z0.d }, p0, [x0, x8, lsl #3] + ldr x9, [x0, #512] + ldr x10, [x0, #520] + lsl x9, x9, #2 + lsl x10, x10, #2 + ldr x9, [x9, x1] + str x9, [x0, #512] + ldr x9, [x0, #528] + ldr x10, [x10, x1] + lsl x9, x9, #2 + str x10, [x0, #520] + ldr x10, [x0, #536] + ldr x9, [x9, x1] + lsl x10, x10, #2 + str x9, [x0, #528] + ldr x9, [x10, x1] + str x9, [x0, #536] + ld1d { z0.d }, p0/z, [x0, x8, lsl #3] + ret +GatherLoad4_u64(ContextObject*, __SVBool_t, unsigned long*, __SVUint64_t): // @GatherLoad4_u64(ContextObject*, __SVBool_t, unsigned long*, __SVUint64_t) + mov x8, #64 // =0x40 + st1d { z0.d }, p0, [x0, x8, lsl #3] + ldr x9, [x0, #512] + ldr x10, [x0, #520] + lsl x9, x9, #4 + lsl x10, x10, #4 + ldr x9, [x9, x1] + str x9, [x0, #512] + ldr x9, [x0, #528] + ldr x10, [x10, x1] + lsl x9, x9, #4 + str x10, [x0, #520] + ldr x10, [x0, #536] + ldr x9, [x9, x1] + lsl x10, x10, #4 + str x9, [x0, #528] + ldr x9, [x10, x1] + str x9, [x0, #536] + ld1d { z0.d }, p0/z, [x0, x8, lsl #3] + ret +GatherLoad8_u64(ContextObject*, __SVBool_t, unsigned long*, __SVUint64_t): // @GatherLoad8_u64(ContextObject*, __SVBool_t, unsigned long*, __SVUint64_t) + ld1d { z0.d }, p0/z, [x1, z0.d, lsl #3] + ret +``` + +</details> + +The index scaling versions that don't match ARM SVE behaviour is particularly nasty but should hopefully not happen too frequently in practice. + +The index scaling versions without SVE-256 fall down the worst case path of being basically ASIMD, which can be cleaned up slightly when inside the JIT but is pretty bad. + +The index scaling versions that do match SVE behaviour go from 1 instruction with SVE to 7, so it's a bit spicy. +If the gather operations are implemented with only an ASIMD implementation then it turns in to the equivalent of not matching SVE scaling behaviour with 128-bit operations (pretty bad). + +Once we support AVX gather loadstores then this documentation ticket can be closed. diff --git a/results/scraper/fex/3662 b/results/scraper/fex/3662 new file mode 100644 index 000000000..084b15db4 --- /dev/null +++ b/results/scraper/fex/3662 @@ -0,0 +1,4 @@ +Darwinia Linux bugs +Darwinia doing incorrect chdir with proc/self? + +Seems to break the game from Lina's stream. Needs some poking. \ No newline at end of file diff --git a/results/scraper/fex/3663 b/results/scraper/fex/3663 new file mode 100644 index 000000000..344a46922 --- /dev/null +++ b/results/scraper/fex/3663 @@ -0,0 +1,9 @@ +Look in to optimizing PCMPESTR* +A Hat In Time's Menu abuses the instruction in both the main menu and in-game. See if we can make it go faster. + +Ideally the SVE `NMATCH` or `MATCH` instruction can be used to emulate the feature. +The hot loop uses both ECX result and flag result depending on where it is in the loop. + +Comes from vcruntime140.dll, wcsstr. A micro bench would be quite easy to generate. + + diff --git a/results/scraper/fex/3668 b/results/scraper/fex/3668 new file mode 100644 index 000000000..8d07e2388 --- /dev/null +++ b/results/scraper/fex/3668 @@ -0,0 +1,2 @@ +FEZ Crashing? +Happened for Lina, probably not related to the Darwinia bug. Needs a repro and check. \ No newline at end of file diff --git a/results/scraper/fex/3670 b/results/scraper/fex/3670 new file mode 100644 index 000000000..b991ac2b1 --- /dev/null +++ b/results/scraper/fex/3670 @@ -0,0 +1,27 @@ +Fallout: New Vegas slow in-game due to x87 soft float +Both its primary thread and another logic thread are maxing out two CPU cores due to x87 soft float. +This game requires softfloat because logic is otherwise broken with reduced precision mode. +- NPCs stop walking +- Character movement with keyboard does stutter stepping + +``` +Tested by walking outside of the starting house and staring directly at the floor. + +// Primary Thread +// 27.2% - In X87 softfloat handlers + +// Logic Thread? - Total 50.65% +// 7.58% - F80ADD +// 6.9% - softfloat_roundPackToExtF80 +// 6.76% - F80SUB +// 5.60% - softfloat_subMagsExtF80 +// 4.77% + 0.14% - F80CVT +// 4.62% + 0.18% - F80CVTTO +// 3.47% - softfloat_addMagsExtF80 +// 3.33% - extF80_mul +// 2.77% - softfloat_roundPackToF32 +// 2.06% - f32_to_extF80 +// 1.65% - F80MUL +// 0.51% - F80CVTINT +// 0.31% - F80CMP +``` \ No newline at end of file diff --git a/results/scraper/fex/3671 b/results/scraper/fex/3671 new file mode 100644 index 000000000..b0fac015d --- /dev/null +++ b/results/scraper/fex/3671 @@ -0,0 +1,50 @@ +Airscape: The Fall Of Gravity +From: https://store.steampowered.com/app/317250/Airscape__The_Fall_of_Gravity/ + +This is a v8 embedded chrome game. Native Linux game. + + It looks like it runs with `--no-sandbox` so it isn't seccomp problems. +Crashes very early and then hangs infinitely. + +``` +[1868956:0529/055235:ERROR:nss_util.cc(1018)] Failed to load NSS libraries. +[1868953:0529/055242:INFO:CONSOLE(1)] ""process.mainModule.filename: /tmp/.org.chromium.Chromium.VKPExz/index.html"", source: process_main (1) + + +# +# Fatal error in ../../v8/src/ic.cc, line 2716 +# CHECK(stub.FindCodeInCache(&code, target->GetIsolate())) failed +# + +==== C stack trace =============================== + + 1: ?? + 2: ?? + 3: ?? + 4: ?? + 5: ?? + 6: ?? + 7: ?? + 8: ?? + 9: ?? +10: ?? +11: ?? +12: ?? +13: ?? +14: ?? +15: ?? +16: ?? +17: ?? +18: ?? +19: ?? +20: ?? +21: ?? +22: ?? +23: ?? +24: ?? +25: ?? +[1868953:0529/055245:ERROR:crash_handler_host_linux.cc(201)] Received death signal message with the wrong size; msg.msg_controllen:48 msg.msg_flags:0 kCrashContextSize:592 kControlMsgSize:44 +``` + + +The Proton version of the game gets farther, it creates a window before exploding without any messages. \ No newline at end of file diff --git a/results/scraper/fex/3672 b/results/scraper/fex/3672 new file mode 100644 index 000000000..460538c9a --- /dev/null +++ b/results/scraper/fex/3672 @@ -0,0 +1,4 @@ +ConstProp is missing a bunch of AddShift optimizations for loadstore addresses +A bunch of the ConstProp pass with loadstore address generation is looking for OP_ADD instead of OP_ADD and OP_ADDSHIFT. This has made loadstores a bit less effectively in the case where semantics match. + +Remembered this when writing #3669, and @alyssarosenzweig said they were going to look more in to it a while ago. \ No newline at end of file diff --git a/results/scraper/fex/3675 b/results/scraper/fex/3675 new file mode 100644 index 000000000..2a4727877 --- /dev/null +++ b/results/scraper/fex/3675 @@ -0,0 +1,33 @@ +Sifu and RDR break FEX's SMC tracking logic +Both Sifu and RDR break FEX's SMC tracking logic due to the ordering it does mprotects in. Nailed down where it is happening, now I just need to fix it. + +small unittest which reproduces without running the full game. +```cpp +#include <cstdint> +#include <sys/mman.h> +#include <unistd.h> +#include <sys/syscall.h> + +int main() { + + // Original: + // Base: 0x6ffffc0b8000 + // PtrHigh: 0x6ffffc0be000 (+0x6000) + // PtrLow: 0x6ffffc0bd000 (+0x5000) + const uint64_t PtrBase = 0x10'0000; + const uint64_t PtrLow = PtrBase + 0x1000; + const uint64_t PtrLowSize = 0x2000; + const uint64_t PtrHigh = PtrBase + 0x2000; + const uint64_t PtrHighSize = 0x1000; + const uint64_t TotalSize = PtrHigh + 0x1000 - PtrBase; + + (void)mmap((void*)PtrBase, TotalSize, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0); + + // Order matters. + mprotect((void*)PtrHigh, PtrHighSize, PROT_READ); + mprotect((void*)PtrLow, PtrLowSize, PROT_READ); + + ::syscall(SYS_exit_group, 0); + return 0; +} +``` \ No newline at end of file diff --git a/results/scraper/fex/3677 b/results/scraper/fex/3677 new file mode 100644 index 000000000..4eba5cec9 --- /dev/null +++ b/results/scraper/fex/3677 @@ -0,0 +1,6 @@ +Begin migrating from fmt to c++20 format +libstdc++ and libc++ on all of our supported distros is now new enough to support <format>. + +This should be mostly straightforward to implement, the only weird one will be fextl::fmt::vformat since it uses the fmt::basic_memory_buffer for custom allocator support. There's no direct 1:1 replacement in the C++ standard so will need some massaging. + +This will remove one more external project dependency in a relatively straight forward way. Low-prio but shouldn't be terrible to do. \ No newline at end of file diff --git a/results/scraper/fex/368 b/results/scraper/fex/368 new file mode 100644 index 000000000..e7c21f78d --- /dev/null +++ b/results/scraper/fex/368 @@ -0,0 +1,5 @@ +Allow POSIX tests to be disabled between CPU backends +The interpreter currently isn't reentrant safe. +This means we are disabling a bunch of posix tests atm because of this. +We should have two different files for disabled tests, one for interpreter and one for IRJIT. +That way we can keep running JIT posix tests and disable the problematic ones on the interpreter. \ No newline at end of file diff --git a/results/scraper/fex/3685 b/results/scraper/fex/3685 new file mode 100644 index 000000000..59be56dbb --- /dev/null +++ b/results/scraper/fex/3685 @@ -0,0 +1,6 @@ +Tohou: Luna Nights tile x87 precision issue +For some reason when we run with x87 this game has tile rendering issues. When turning on x87 reduced precision the problem goes away. + +This could be an issue with us not handling x87 precision modes correctly? + + diff --git a/results/scraper/fex/3686 b/results/scraper/fex/3686 new file mode 100644 index 000000000..45d983d92 --- /dev/null +++ b/results/scraper/fex/3686 @@ -0,0 +1,10 @@ +Unity games hanging +Noticed this recently, Unity games are likely to hang early with a black screen. +Working: FEX-2405 +Notworking: 314fea36b4420f648a209b8c9ec589eecef35f8d + +Bisecting range is relatively small. + +Known hanging game is Donut County but I've seen various other Unity games that are also affected. + +Supposedly "Dave The Diver" Should work on the newer commit but doesn't work on the older commit? Will need testing. \ No newline at end of file diff --git a/results/scraper/fex/3687 b/results/scraper/fex/3687 new file mode 100644 index 000000000..7a200101e --- /dev/null +++ b/results/scraper/fex/3687 @@ -0,0 +1,5 @@ +Fix Thunk/VDSO loading in a chroot. +Brought up on Discord that thunks aren't available in a chroot. +At the very least we should fix VDSO since random applications will break without VDSO, maybe hardcoding the two binaries in to FEXInterpreter as a build step. + +OpenGL and Vulkan thunking inside of a chroot is less interesting since it is only a performance improvement rather than potential compatibility issues. \ No newline at end of file diff --git a/results/scraper/fex/3690 b/results/scraper/fex/3690 new file mode 100644 index 000000000..4806b6f69 --- /dev/null +++ b/results/scraper/fex/3690 @@ -0,0 +1,17 @@ +asm_tests failing on HDK8650 +Currently, and since 2e40da3d6b448598f6d86033b33f2a630357520b , the following asm_tests are failing: + +``` +The following tests FAILED: + 4977 - jit_1/Test_64Bit_REP/F3_C2.asm (Failed) + 4978 - jit_500/Test_64Bit_REP/F3_C2.asm (Failed) + 4979 - jit_500_m/Test_64Bit_REP/F3_C2.asm (Failed) + 5052 - jit_1/Test_64Bit_REPNE/F2_C2.asm (Failed) + 5053 - jit_500/Test_64Bit_REPNE/F2_C2.asm (Failed) + 5054 - jit_500_m/Test_64Bit_REPNE/F2_C2.asm (Failed) + 5394 - jit_1/Test_64Bit_TwoByte/0F_2A.asm (Failed) + 5395 - jit_500/Test_64Bit_TwoByte/0F_2A.asm (Failed) + 5396 - jit_500_m/Test_64Bit_TwoByte/0F_2A.asm (Failed) +``` + +This seems to be related to enabling AFP and RPRES in 2e40da3d6b448598f6d86033b33f2a630357520b. \ No newline at end of file diff --git a/results/scraper/fex/3691 b/results/scraper/fex/3691 new file mode 100644 index 000000000..80f000437 --- /dev/null +++ b/results/scraper/fex/3691 @@ -0,0 +1,103 @@ +Unhandled exception when starting any FEX* command +After error during `FEXRootFSFetcher`'s "unpacking fs image" phase +``` +Do you wish to extract the erofs file or use it as-is? +Options: + 0: Cancel + 1: Extract + 2: As-Is + +Response {1-2} or 0 to cancel +1 +Extracting Erofs. This might take a few minutes. +<E> erofs: I/O error occurred when verifying data chunk @ nid 31192463 +Do you wish to set this RootFS as default? +Response {y,yes,1} or {n,no,0} +y +Ubuntu_23_04.ero set as default RootFS +``` + + + any Fex* command return this error: +``` +> FEXRootFSFetcher +terminate called after throwing an instance of 'std::out_of_range' + what(): vector::_M_range_check: __n (which is 0) >= this->size() (which is 0) +fish: Job 1, 'FEXRootFSFetcher' terminated by signal SIGABRT (Abort) +``` +FEXConfig spawns window, but then fail with same error +``` +> FEXConfig +terminate called after throwing an instance of 'std::out_of_range' + what(): vector::_M_range_check: __n (which is 0) >= this->size() (which is 0) +fish: Job 1, 'FEXConfig' terminated by signal SIGABRT (Abort) +``` + +### Steps to reproduce +#### Build +```sh +mkdir build +cd build +env CC=clang CXX=clang++ cmake .. -G Ninja -D ENABLE_LTO=False -D BUILD_TESTS=False -D CMAKE_BUILD_TYPE=Release -D INTERPROCEDURAL_OPTIMIZATION=False + +sudo ninja install +``` +#### Run + +FEXRootFSFetcher +Select Ubuntu 23 erofs image + +### Addition info + +os-release +``` +NAME="Manjaro ARM" +ID="manjaro-arm" +``` + +lscpu +``` +Architecture: aarch64 + CPU op-mode(s): 32-bit, 64-bit + Byte Order: Little Endian +CPU(s): 6 + On-line CPU(s) list: 0-5 +Vendor ID: ARM + Model name: Cortex-A53 + Model: 4 + Thread(s) per core: 1 + Core(s) per socket: 4 + Socket(s): 1 + Stepping: r0p4 + CPU(s) scaling MHz: 58% + CPU max MHz: 1416.0000 + CPU min MHz: 408.0000 + BogoMIPS: 48.00 + Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid + Model name: Cortex-A72 + Model: 2 + Thread(s) per core: 1 + Core(s) per socket: 2 + Socket(s): 1 + Stepping: r0p2 + CPU(s) scaling MHz: 100% + CPU max MHz: 1800.0000 + CPU min MHz: 408.0000 + BogoMIPS: 48.00 + Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid +Vulnerabilities: + Gather data sampling: Not affected + Itlb multihit: Not affected + L1tf: Not affected + Mds: Not affected + Meltdown: Not affected + Mmio stale data: Not affected + Retbleed: Not affected + Spec rstack overflow: Not affected + Spec store bypass: Vulnerable + Spectre v1: Mitigation; __user pointer sanitization + Spectre v2: Vulnerable + Srbds: Not affected + Tsx async abort: Not affected +``` + diff --git a/results/scraper/fex/3696 b/results/scraper/fex/3696 new file mode 100644 index 000000000..f209531cf --- /dev/null +++ b/results/scraper/fex/3696 @@ -0,0 +1,2 @@ +Why is FEX not working for me? +I compiled FEX (from git) on my Raspberry Pi 4 and I am unable to launch Wine, Discord, Steam, etc. Are these programs known to be problematic with FEX or did I potentially do something wrong. If the latter, then I'll do whatever is needed to show my end. \ No newline at end of file diff --git a/results/scraper/fex/3698 b/results/scraper/fex/3698 new file mode 100644 index 000000000..f015ead57 --- /dev/null +++ b/results/scraper/fex/3698 @@ -0,0 +1,4 @@ +Unclear FexConfig setting +What `FexConfig`'s `Hacks` -> `TSO Enable` do? +Does it means 'Your cpu supports TSO' or 'TSO emulation' ? + diff --git a/results/scraper/fex/3702 b/results/scraper/fex/3702 new file mode 100644 index 000000000..bee657250 --- /dev/null +++ b/results/scraper/fex/3702 @@ -0,0 +1,2 @@ +Disable optimization passes broken +CondJump at the very least requires InlineConstants. Not sure what else fails right now. \ No newline at end of file diff --git a/results/scraper/fex/3713 b/results/scraper/fex/3713 new file mode 100644 index 000000000..b55936abc --- /dev/null +++ b/results/scraper/fex/3713 @@ -0,0 +1,13 @@ +Eliminate adr+str InlineJITBlockHeader +What is the inlinejitblockheader for exactly? + +> It's what we use for RIP reconstruction + +Why can't we keep a table of host pc --> guest rip and just look at the regular backtrace? + +> Once we support deferring async signals inside the JIT, we can +> I also did some benchmarking to see the overhead for the adr+str and it fell within noise. It's single cycle + single cycle so it is hard to beat + +But on my end multiblock sped up bytemark a lot and I don't think DSE is the reason 😉 + +Tracker for later. \ No newline at end of file diff --git a/results/scraper/fex/3753 b/results/scraper/fex/3753 new file mode 100644 index 000000000..2e5da82d2 --- /dev/null +++ b/results/scraper/fex/3753 @@ -0,0 +1,3 @@ +Extend vinsert unit tests to ensure correct behaviour with "bad" masks +Current vinsert{i128,f128} tests only test for literal 0 or 1, we should have tests with the high bits set to ensure correct behaviour. +Almost had a behaviour change in a PR that woudn't have been caught. \ No newline at end of file diff --git a/results/scraper/fex/3782 b/results/scraper/fex/3782 new file mode 100644 index 000000000..5831076c5 --- /dev/null +++ b/results/scraper/fex/3782 @@ -0,0 +1,27 @@ +AVX128: 256-bit vmovmsk can be improved +```json + "vmovmskps rax, ymm0": { + "ExpectedInstructionCount": 11, + "Comment": [ + "Map 1 0b00 0x50 256-bit" + ], + "ExpectedArm64ASM": [ + "ldr q2, [x28, #16]", + "ushr v3.4s, v16.4s, #31", + "ldr q4, [x28, #2512]", + "ushl v3.4s, v3.4s, v4.4s", + "addv s3, v3.4s", + "mov w20, v3.s[0]", + "ushr v2.4s, v2.4s, #31", + "ushl v2.4s, v2.4s, v4.4s", + "addv s2, v2.4s", + "mov w21, v2.s[0]", + "orr x4, x20, x21, lsl #4" + ] +``` +Current algorithm just does two 128-bit algorithms and then merges at the end. + +This can be improved by loading a second shift value for the high 128-bits which shifts the signs in to different locations. Then do a add between the two 128-bit halves, then a horizontal add, single FPR->GPR element extract. +Would shave the instructions from 11 to 10, removing a horizontal add and a FPR->GPR transfer. + +vmovmskpd is similar in that it is doing two 128-bit algorithms and then extracting. Different algorithm so it would need more noodling. \ No newline at end of file diff --git a/results/scraper/fex/3784 b/results/scraper/fex/3784 new file mode 100644 index 000000000..715421d21 --- /dev/null +++ b/results/scraper/fex/3784 @@ -0,0 +1,2 @@ +AVX128: vpshufd can be improved +The implementation is just using the basic VInsElement loop for both 128-bit and 256-bit, this can be improved dramatically. \ No newline at end of file diff --git a/results/scraper/fex/3785 b/results/scraper/fex/3785 new file mode 100644 index 000000000..ca4a2fceb --- /dev/null +++ b/results/scraper/fex/3785 @@ -0,0 +1,2 @@ +AVX128: vpshuflw/vpshufhw can be improved +Similar to #3784, this is just using a simple vinselement loop instead of anything smart, can be improved dramatically. \ No newline at end of file diff --git a/results/scraper/fex/3787 b/results/scraper/fex/3787 new file mode 100644 index 000000000..7f402271f --- /dev/null +++ b/results/scraper/fex/3787 @@ -0,0 +1,18 @@ +AVX128: vmovq can be improved +```json + "vmovq xmm0, qword [rax]": { + "ExpectedInstructionCount": 4, + "Comment": [ + "Map 1 0b01 0x6e 128-bit" + ], + "ExpectedArm64ASM": [ + "ldr q2, [x4]", + "mov v16.8b, v2.8b", + "movi v2.2d, #0x0", + "str q2, [x28, #16]" + ] + }, +``` +Moves in to a temporary first before copying to the final destination for some reason. + +vmovdqa and vmovdqu don't seem to have the same problem. \ No newline at end of file diff --git a/results/scraper/fex/3788 b/results/scraper/fex/3788 new file mode 100644 index 000000000..8f03370fd --- /dev/null +++ b/results/scraper/fex/3788 @@ -0,0 +1,21 @@ +AVX128: 256-bit stores to memory can be converted to store pairs +Example: +```json + "vmovdqa [rax], ymm0": { + "ExpectedInstructionCount": 3, + "Comment": [ + "Map 1 0b01 0x7f 128-bit" + ], + "ExpectedArm64ASM": [ + "ldr q2, [x28, #16]", + "str q16, [x4]", + "str q2, [x4, #16]" + ] + }, + ``` + +A little quirky since some care should be taken for the address calculation overhead, but today we currently implement these stores as two 128-bit stores. When vector TSO emulation is enabled, this turns in to dmb+str+dmb+str, if we were using pair stores this would turn in to a single dmb+stp pairing, eating a little bit of ALU work if we can't synthesize the SIB addressing directly. + +Additionally FEAT_LRCPC3 adds the STLUR and LDAPUR x86-TSO instructions, which we would probably want to choose to use in the backend instead when Vector TSO is enabled. For example the `dmb+stp` instruction pairing would turn in to `stlur+stlur` since that would be more efficient in that case. Similar story for the load side, but we don't have a good solution for returning a pair of registers atm. + +No hardware supports FEAT_LRCPC3 today so that particular edge case isn't very interesting. \ No newline at end of file diff --git a/results/scraper/fex/3790 b/results/scraper/fex/3790 new file mode 100644 index 000000000..f50b1537c --- /dev/null +++ b/results/scraper/fex/3790 @@ -0,0 +1,6 @@ +AVX128: Implement SSE4.1 non-temporal loads with SVE LDNT1B +SSE4.1 introduced the 128-bit `MOVNTDQA` instruction +This can be implemented with the SVE LDNT1B instruction + +Additionally AVX2 extends this to a 256-bit version, which can be implemented with ASIMD LDNP. +Should be fairly similar to the store non-temporal version, just doesn't need to workaround the scalar and mmx variants since they don't exist. \ No newline at end of file diff --git a/results/scraper/fex/3791 b/results/scraper/fex/3791 new file mode 100644 index 000000000..7eed39dba --- /dev/null +++ b/results/scraper/fex/3791 @@ -0,0 +1,27 @@ +AVX128: Optimize 256-bit contiguous masked loadstore with immediate offset +Currently the SVE contiguous masked load splits the instruction in to two with an add in the middle for address generation. +We can remove that add inbetween the two halves because the `ld1w` and `ld1d` instructions support a short immediate offset multiplied by VL. + +```json + "vmaskmovps ymm0, ymm1, [rax]": { + "ExpectedInstructionCount": 9, + "Comment": [ + "Map 2 0b01 0x2c 256-bit" + ], + "ExpectedArm64ASM": [ + "ldr q2, [x28, #32]", + "mrs x20, nzcv", + "cmplt p0.s, p6/z, z17.s, #0", + "ld1w {z16.s}, p0/z, [x4]", + "add x21, x4, #0x10 (16)", <------------- This add + "cmplt p0.s, p6/z, z2.s, #0", + "ld1w {z2.s}, p0/z, [x21]", <-------------- Can be rolled in to this instruction + "msr nzcv, x20", + "str q2, [x28, #16]" + ] + }, +``` + +Only saves a single instruction for both 256-bit `vmaskmovps` and `vmaskmovpd` but is fairly trivial do do. + +Same thing can be improved on the store side as well. \ No newline at end of file diff --git a/results/scraper/fex/3793 b/results/scraper/fex/3793 new file mode 100644 index 000000000..4cd2dceb8 --- /dev/null +++ b/results/scraper/fex/3793 @@ -0,0 +1,4 @@ +AVX128: Scalar FMA can be optimized with AFP.NEP +Currently scalar FMA eats the insert after calculation even when AFP.NEP is supported. This is because I didn't implement the AFP.NEP path. + +Will cut the scalar FMA implementation by one instruction in those cases, just needs to be implemented. \ No newline at end of file diff --git a/results/scraper/fex/3794 b/results/scraper/fex/3794 new file mode 100644 index 000000000..90ab2e99b --- /dev/null +++ b/results/scraper/fex/3794 @@ -0,0 +1,158 @@ +AVX128: Some FMA instruction having extraneous moves +Haven't looked at why these are occuring, maybe the backend implementation needs to check if destination isn't one of the incoming sources? Doesn't occur on the SVE side. The 231 variants are the most interesting here since they shouldn't need any redundant moves unless potentially one of the other sources overlaps the destination (In the case that a negation is needed). + +<details> + <summary>Negated FMA ops</summary> + +```json + "vfmsub231ps xmm0, xmm1, xmm2": { + "ExpectedInstructionCount": 5, + "Comment": [ + "Map 2 0b01 0xba 128-bit" + ], + "ExpectedArm64ASM": [ + "fneg v0.4s, v16.4s", + "fmla v0.4s, v17.4s, v18.4s", + "mov v16.16b, v0.16b", + "movi v2.2d, #0x0", + "str q2, [x28, #16]" + ] + }, + "vfmsub231ps ymm0, ymm1, ymm2": { + "ExpectedInstructionCount": 10, + "Comment": [ + "Map 2 0b01 0xba 256-bit" + ], + "ExpectedArm64ASM": [ + "ldr q2, [x28, #16]", + "ldr q3, [x28, #32]", + "ldr q4, [x28, #48]", + "fneg v0.4s, v16.4s", + "fmla v0.4s, v17.4s, v18.4s", + "mov v16.16b, v0.16b", + "fneg v0.4s, v2.4s", + "fmla v0.4s, v3.4s, v4.4s", + "mov v2.16b, v0.16b", + "str q2, [x28, #16]" + ] + }, + "vfmsub231pd xmm0, xmm1, xmm2": { + "ExpectedInstructionCount": 5, + "Comment": [ + "Map 2 0b01 0xba 128-bit" + ], + "ExpectedArm64ASM": [ + "fneg v0.2d, v16.2d", + "fmla v0.2d, v17.2d, v18.2d", + "mov v16.16b, v0.16b", + "movi v2.2d, #0x0", + "str q2, [x28, #16]" + ] + }, + "vfmsub231pd ymm0, ymm1, ymm2": { + "ExpectedInstructionCount": 10, + "Comment": [ + "Map 2 0b01 0xba 256-bit" + ], + "ExpectedArm64ASM": [ + "ldr q2, [x28, #16]", + "ldr q3, [x28, #32]", + "ldr q4, [x28, #48]", + "fneg v0.2d, v16.2d", + "fmla v0.2d, v17.2d, v18.2d", + "mov v16.16b, v0.16b", + "fneg v0.2d, v2.2d", + "fmla v0.2d, v3.2d, v4.2d", + "mov v2.16b, v0.16b", + "str q2, [x28, #16]" + ] + }, + "vfnmsub231ps xmm0, xmm1, xmm2": { + "ExpectedInstructionCount": 5, + "Comment": [ + "Map 2 0b01 0xbe 128-bit" + ], + "ExpectedArm64ASM": [ + "fneg v0.4s, v16.4s", + "fmls v0.4s, v17.4s, v18.4s", + "mov v16.16b, v0.16b", + "movi v2.2d, #0x0", + "str q2, [x28, #16]" + ] + }, + "vfnmsub231ps ymm0, ymm1, ymm2": { + "ExpectedInstructionCount": 10, + "Comment": [ + "Map 2 0b01 0xbe 256-bit" + ], + "ExpectedArm64ASM": [ + "ldr q2, [x28, #16]", + "ldr q3, [x28, #32]", + "ldr q4, [x28, #48]", + "fneg v0.4s, v16.4s", + "fmls v0.4s, v17.4s, v18.4s", + "mov v16.16b, v0.16b", + "fneg v0.4s, v2.4s", + "fmls v0.4s, v3.4s, v4.4s", + "mov v2.16b, v0.16b", + "str q2, [x28, #16]" + ] + }, + "vfnmsub231pd xmm0, xmm1, xmm2": { + "ExpectedInstructionCount": 5, + "Comment": [ + "Map 2 0b01 0xbe 128-bit" + ], + "ExpectedArm64ASM": [ + "fneg v0.2d, v16.2d", + "fmls v0.2d, v17.2d, v18.2d", + "mov v16.16b, v0.16b", + "movi v2.2d, #0x0", + "str q2, [x28, #16]" + ] + }, + "vfnmsub231pd ymm0, ymm1, ymm2": { + "ExpectedInstructionCount": 10, + "Comment": [ + "Map 2 0b01 0xbe 256-bit" + ], + "ExpectedArm64ASM": [ + "ldr q2, [x28, #16]", + "ldr q3, [x28, #32]", + "ldr q4, [x28, #48]", + "fneg v0.2d, v16.2d", + "fmls v0.2d, v17.2d, v18.2d", + "mov v16.16b, v0.16b", + "fneg v0.2d, v2.2d", + "fmls v0.2d, v3.2d, v4.2d", + "mov v2.16b, v0.16b", + "str q2, [x28, #16]" + ] + }, +``` +</details> + +Additionally the addsubs have some extraneous moves as well due to the negations occuring, which should be able to be resolved. This happens on both the ASIMD and SVE sides. + +<details> + <summary>addsub/subadd ops</summary> + +``` + "vfmaddsub231ps xmm0, xmm1, xmm2": { + "ExpectedInstructionCount": 7, + "Comment": [ + "Map 2 0b01 0xb6 128-bit" + ], + "ExpectedArm64ASM": [ + "ldr q2, [x28, #2384]", + "eor v2.16b, v16.16b, v2.16b", + "mov v0.16b, v2.16b", + "fmla v0.4s, v17.4s, v18.4s", + "mov v16.16b, v0.16b", + "movi v2.2d, #0x0", + "str q2, [x28, #16]" + ] + }, +... etc, etc +``` +</details> diff --git a/results/scraper/fex/3795 b/results/scraper/fex/3795 new file mode 100644 index 000000000..7554a08f8 --- /dev/null +++ b/results/scraper/fex/3795 @@ -0,0 +1,27 @@ +AVX128: VPERM{Q,PD} can be more optimized +We only hand optimize four selectors out of the total 256. Anything that falls out of those four turns in to a zero-register plus four inserts which is pretty bad. We don't have these sitting in instcountci at all right now. + +An example of the bad output. +```json + "vpermpd ymm0, ymm1, 01101011b": { + "ExpectedInstructionCount": 9, + "Comment": [ + "Map 3 0b01 0x01 256-bit" + ], + "ExpectedArm64ASM": [ + "ldr q2, [x28, #32]", + "movi v3.2d, #0x0", + "mov v4.16b, v3.16b", + "mov v4.d[0], v2.d[1]", + "mov v16.16b, v4.16b", + "mov v16.d[1], v2.d[0]", + "mov v3.d[0], v2.d[0]", + "mov v3.d[1], v17.d[1]", + "str q3, [x28, #16]" + ] + }, +``` + +Theoretically worst case should devolve in to a TBL2 instruction which would be better than that mess of inserts, and of course we should support solving more selectors with handwritten optimizations. + +VPERMQ and VPERMPD are aliases of each other so they behave the same. \ No newline at end of file diff --git a/results/scraper/fex/3796 b/results/scraper/fex/3796 new file mode 100644 index 000000000..906a26818 --- /dev/null +++ b/results/scraper/fex/3796 @@ -0,0 +1,11 @@ +AVX128: Blends with immediate selector completely unoptimized +This includes the whole family of blends: +16-bit: VPBLENDW +32-bit: VPBLENDD, VBLENDPS +64-bit: VBLENDPD + +64-bit blend is definitely the easiest where we should be able to move or zip depending. + +32-bit and 16-bit get a bit more spicy. + +These are all currently implemented with just a loop of inserts in to a zero register, so they are quite low performance atm. \ No newline at end of file diff --git a/results/scraper/fex/3797 b/results/scraper/fex/3797 new file mode 100644 index 000000000..90afab402 --- /dev/null +++ b/results/scraper/fex/3797 @@ -0,0 +1,4 @@ +AVX128: VPERMIL{PS,PD} completely unoptimized +Similar to #3796, these are completely decomposed to zero register and inserts. + +64-bit would be fairly easy with zips and 32-bit selections should be similar to other 32-bit shuffles/permutes \ No newline at end of file diff --git a/results/scraper/fex/3799 b/results/scraper/fex/3799 new file mode 100644 index 000000000..d891677ba --- /dev/null +++ b/results/scraper/fex/3799 @@ -0,0 +1,92 @@ +SVE256: AVX implementation fails to retain upper 128-bits of results +We don't have any unit tests that aggressively mix SSE and AVX unit tests. In some (most?) cases the SVE256 bit implementation of our AVX emulation doesn't correctly retain the upper 128-bits of the register when an SSE operation occurs. + +This can be seen in the following unit test: +```asm +%ifdef CONFIG +{ + "RegData": { + "XMM0": ["0xfdecd28fab3fa4a5", "0x7d7ccd8836d09fc2", "0xccdbcfc31f3ff0f3", "0x108390defebac4be"], + "XMM1": ["0xc4be43cc1ad6970b", "0x4559bd7eb46a1278", "0", "0"], + "XMM2": ["0xc4be43cc1ad6970b", "0x4549bd7eb46a1278", "0xf793ef673dac6e4c", "0xbb7b5b3d85d34271"], + "XMM3": ["0x000043cc1ad6970b", "0x4549bd7eb46a1278", "0xf793ef673dac6e4c", "0xbb7b5b3d85d34271"] + } +} +%endif + +vmovaps ymm0, [rel .data] +vmovaps ymm1, [rel .data + (1 * 32)] +vmovaps ymm2, [rel .data + (2 * 32)] +vmovaps ymm3, [rel .data + (3 * 32)] + +addpd xmm0, xmm1 +vaddpd xmm1, xmm2, xmm3 + +hlt + +align 32 +.data: +dq 0xfdecd28fab3fa4a5, 0x7d7ccd8836d09fc2, 0xccdbcfc31f3ff0f3, 0x108390defebac4be +dq 0x43cc1ad6970b4549, 0xbd7eb46a1278f793, 0xef673dac6e4cbb7b, 0x5b3d85d342718be9 +dq 0xc4be43cc1ad6970b, 0x4549bd7eb46a1278, 0xf793ef673dac6e4c, 0xbb7b5b3d85d34271 +dq 0x000043cc1ad6970b, 0x4549bd7eb46a1278, 0xf793ef673dac6e4c, 0xbb7b5b3d85d34271 +``` + +This unit test works with ASIMD and SVE128, but fails with SVE256. Looking at an instcountci test shows why this occurs + +First with ASIMD/SVE128: +```json + "addpd xmm0, xmm1": { + "ExpectedInstructionCount": 1, + "Comment": [ + "Map 1 0b00 0x10 128-bit" + ], + "ExpectedArm64ASM": [ + "fadd v16.2d, v16.2d, v17.2d" + ] + }, + "vaddpd xmm0, xmm0, xmm1": { + "ExpectedInstructionCount": 3, + "Comment": [ + "Map 1 0b00 0x10 128-bit" + ], + "ExpectedArm64ASM": [ + "fadd v16.2d, v16.2d, v17.2d", + "movi v2.2d, #0x0", + "str q2, [x28, #16]" + ] + }, +``` + +Next with SVE256: +```json + "addpd xmm0, xmm1": { + "ExpectedInstructionCount": 1, + "Comment": [ + "Map 1 0b00 0x10 128-bit" + ], + "ExpectedArm64ASM": [ + "fadd v16.2d, v16.2d, v17.2d" + ] + }, + "vaddpd xmm0, xmm0, xmm1": { + "ExpectedInstructionCount": 1, + "Comment": [ + "Map 1 0b00 0x10 128-bit" + ], + "ExpectedArm64ASM": [ + "fadd v16.2d, v16.2d, v17.2d" + ] + }, +``` + +As seen, the addpd and vaddpd behaviour is different on ASIMD/SVE128 versus SVE256. +SSE addpd: +- ASIMD: gains insert capability because of discontiguous registers ✅ +- SVE256: zero-extends due to ASIMD results zero extending ❌ + +AVX vaddpd: +- ASIMD: Lower 128-bits is calculated correctly. Additional mov+str for upper 128-bit zext. ✅ +- SVE256: Lower 128-bits is calculated and zero-extended correctly using ASIMD semantics ✅ + +SVE256 needs to retain the upper 128-bits of the result register and do an insert when executing an SSE instruction. \ No newline at end of file diff --git a/results/scraper/fex/3805 b/results/scraper/fex/3805 new file mode 100644 index 000000000..f65141530 --- /dev/null +++ b/results/scraper/fex/3805 @@ -0,0 +1,2 @@ +AVX128: Prescale gathers with 64-bit index and scale factor of 2 or 4 +We know that overflow behaviour with 64-bit indexes just throws away the top bits. Instead of falling back to the ASIMD implementation when the scale factor is 2 or 4, just prescale the values in the vector registers and then pass scale to the IR operation as 1. This will let it continue to use the faster SVE codepath while just eating two more instructions compared to 1 or 8 scaling. \ No newline at end of file diff --git a/results/scraper/fex/3806 b/results/scraper/fex/3806 new file mode 100644 index 000000000..c227868cd --- /dev/null +++ b/results/scraper/fex/3806 @@ -0,0 +1,7 @@ +AVX128: Extend 32-bit indices in the case of `VPGATHERDQ ymm1, vm32x, ymm2` +For the particular code path that `VPGATHERDQ ymm1, vm32x, ymm2` hits, we can sign-extend the indices provided in vm32x to be 64-bit indices. +This only really works because we split the IR operation in to two halves anyway, so 4 32-bit indices in vm32x loading 4 64-bit indices in ymm1 works out to two SVE gather loads using 64-bit indices quite well. + +We can also then use the scaling optimization that #3805 proposes since the 32-bit signed indices are guaranteed to overflow correctly in this case. + + diff --git a/results/scraper/fex/3807 b/results/scraper/fex/3807 new file mode 100644 index 000000000..7a53d4e18 --- /dev/null +++ b/results/scraper/fex/3807 @@ -0,0 +1,10 @@ +Portal 2 currently crashes under FEX +Seems to crash with a nullptr deference in their vscript.so library. Not sure what it is doing. Once at the title screen just click "Continue game" and seemingly once it gets done loading it'll crash before it goes in-game. + +Trying to bisect this on the FEX side had me going back to FEX-2301 and still getting the crash. So this seems to have been a change on the Portal 2 side causing issues. + +Doesn't seem to be running out of memory either, so it's a peculiar one. Might need to actually fix the gdbserver to debug this one. + +Didn't try running it under Proton, which might be a viable workaround. + +Dave the Diver and Peggle Deluxe breaking are likely related in some form. \ No newline at end of file diff --git a/results/scraper/fex/3827 b/results/scraper/fex/3827 new file mode 100644 index 000000000..629c2ae3b --- /dev/null +++ b/results/scraper/fex/3827 @@ -0,0 +1,4 @@ +AVX128: `vgatherqps` and `vpgatherqd` might be able to be optimized with `LD1W { <Zt>.D }, <Pg>/Z, [<Xn|SP>, <Zm>.D]` +Currently these operations fall down the ASIMD path universally. We might be able to use this weirdo zero extending gather from SVE and then swizzle the components down to where we want them instead. + +Need to noodle on it a bit. \ No newline at end of file diff --git a/results/scraper/fex/3829 b/results/scraper/fex/3829 new file mode 100644 index 000000000..674c477aa --- /dev/null +++ b/results/scraper/fex/3829 @@ -0,0 +1,4 @@ +AVX128: vpgatherdd/vgatherdps asimd fallbacks should be able to utilize SVE +The versions of vpgatherdd/vgatherdps that fallback to the ASIMD variant should be able to use the QPS variant of the gather load introduced in #3826. + +Gets a bit spicy with the 256-bit destination and 256-bit source versions. I believe we need to sign extend the addr elements to 64-bit, effectively generating 512-bits of address vectors. So it won't be as efficient as the other versions but a heck of a lot better than ASIMD fallback. \ No newline at end of file diff --git a/results/scraper/fex/3830 b/results/scraper/fex/3830 new file mode 100644 index 000000000..cfc9bcce4 --- /dev/null +++ b/results/scraper/fex/3830 @@ -0,0 +1,9 @@ +Wine issues in Fedora 40 +Wine is having problems in Fedora 40. One problem is that execve is leaking the absolute path to wine inside the rootfs. +Additionally if that is fixed/hacked then wine stops finding paths in its z: symlink. + +Seemingly wine changes behaviour if it is executed from its install prefix versus $ROOTFS/$prefix? +Not sure how we haven't hit this before but the behaviour is different between Fedora and Ubuntu which is kind of annoying. +Potentially a Wine 9.0 (Ubuntu) to 9.5 (Fedora) change affecting things? + +Tricky stuff. Will need some extensive testing with Proton to ensure we don't regress anything since the overlayfs is kind of fragile. \ No newline at end of file diff --git a/results/scraper/fex/3838 b/results/scraper/fex/3838 new file mode 100644 index 000000000..36fcc1d0f --- /dev/null +++ b/results/scraper/fex/3838 @@ -0,0 +1,5 @@ +SSE4a +- [ ] EXTRQ/INSERTQ Combined mask-shift instructions. +- [ ] MOVNTSD/MOVNTSS Scalar streaming store instructions. + +Header is [<ammintrin.h>](https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/ammintrin.h;h=b94731a9e2ca64529189a3ed8b16a5147c27c652;hb=HEAD) \ No newline at end of file diff --git a/results/scraper/fex/3839 b/results/scraper/fex/3839 new file mode 100644 index 000000000..cf2143c85 --- /dev/null +++ b/results/scraper/fex/3839 @@ -0,0 +1,3 @@ +FMA4 +[GCC header](https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/fma4intrin.h;h=23d36b9f5fa586a536b1b90d57c179e85f72d2cd;hb=HEAD) +[llvm header](https://github.com/llvm/llvm-project/blob/4998587e6f5f66d464ac22ad4c11fe9afd2d56ab/clang/lib/Headers/fma4intrin.h) \ No newline at end of file diff --git a/results/scraper/fex/3850 b/results/scraper/fex/3850 new file mode 100644 index 000000000..3fda835e4 --- /dev/null +++ b/results/scraper/fex/3850 @@ -0,0 +1,2 @@ +MMX/x87 interaction is subtly broken +MMX is supposed to set the upper bits of the 80-bit x87 register to -1, and also supposed to set certain x87 flags. FEX isn't doing either. I don't know of any applications that rely on this behaviour, but Intel documents it explicitly. \ No newline at end of file diff --git a/results/scraper/fex/3851 b/results/scraper/fex/3851 new file mode 100644 index 000000000..0750742c0 --- /dev/null +++ b/results/scraper/fex/3851 @@ -0,0 +1,2 @@ +PDEP/PEXT can be implemented with SVE2 BDEP/BEXT +Needs to eat Vector<->GPR moves but that is still going to be faster than the looping path. \ No newline at end of file diff --git a/results/scraper/fex/3856 b/results/scraper/fex/3856 new file mode 100644 index 000000000..3e769ca21 --- /dev/null +++ b/results/scraper/fex/3856 @@ -0,0 +1,4 @@ +Implement DAZ using AFP.FIZ +Currently unsupported in FEX but will seemingly fix issues at least in warhammer 40k Gladius where it is doing a vector normalize pass and doing an equality check with zero. It likely generates a denormal with its math and DAZ flattens that to zero. + + diff --git a/results/scraper/fex/3886 b/results/scraper/fex/3886 new file mode 100644 index 000000000..5bb8e8911 --- /dev/null +++ b/results/scraper/fex/3886 @@ -0,0 +1,65 @@ +AVX128: Zeroing of upper bits can be more optimal with 128-bit operation +```json + "vfmadd231ss xmm0, xmm1, xmm2": { + "ExpectedInstructionCount": 3, + "Comment": [ + "Map 2 0b01 0xb9 128-bit" + ], + "ExpectedArm64ASM": [ + "fmadd s16, s17, s18, s16", + "movi v2.2d, #0x0", + "str q2, [x28, #16]" + ] + }, + ``` + +In the common case of an AVX instruction operating at 128-bits we have a movi+str pair to zero the upper 128-bit lane. +There's a couple benefits of this, + +1. We cache this zero register in multiple instruction blocks. This allows multiple 128-bit operations to eat a single move and dead store elimination will eliminate all the stores aside from the last one. +2. The zero register retains the FPRClass to make RA sane. (This is a note for how an improvement can change the class type) + +An annoyance with this approach is that if we know we are storing zero to the upper 128-bit lane, and then storing that zero to the context, it would be more optimal to remove the movi and do an `stp xzr, xzr, [x28, #16]` + +1. This removes the movi instruction +2. This uses a GPR stp instruction which is one cycle on Cortex +3. Removes the movi->stp dependency + +The downside to this approach is if that zero register actually needs to be in a vector register, it gets confusing. Think about a 128-bit AVX instruction zeroing the upper bits, and then a 256-bit AVX instruction doing a vector or or something, merging the bottom 128-bit lane but effectively doing a move to the top 128-bits. Need to be careful not to make the intermixed version worse. Which would likely degrade in to a context store, then load to avoid the RA class mishmash when today it could have just stayed as a living value without hitting context. + +Will need some noodling to figure out what is best here. Maybe we need to pump the `IsInlineConstant` value through from OpcodeDispatcher to backend for vector sources but supporting only the source being `_LoadNamedVectorConstant(Size, IR::NamedVectorConstant::NAMED_VECTOR_ZERO)`? + + +example of what the previous example could turn in to +```json + "vfmadd231ss xmm0, xmm1, xmm2": { + "ExpectedInstructionCount": 2, + "Comment": [ + "Map 2 0b01 0xb9 128-bit" + ], + "ExpectedArm64ASM": [ + "fmadd s16, s17, s18, s16", + "stp xzr, xzr, [x28, #16]" + ] + }, + ``` + + +Example of a test case that we don't want to make worse +```json + "128-bit test": { + "ExpectedInstructionCount": 6, + "x86Insts": [ + "vaddps xmm0, xmm1, xmm2", + "vorps ymm0, ymm3" + ], + "ExpectedArm64ASM": [ + "fadd v16.4s, v17.4s, v18.4s", + "movi v2.2d, #0x0", + "ldr q3, [x28, #64]", + "orr v16.16b, v16.16b, v19.16b", + "orr v2.16b, v2.16b, v3.16b", + "str q2, [x28, #16]" + ] + }, +``` \ No newline at end of file diff --git a/results/scraper/fex/3895 b/results/scraper/fex/3895 new file mode 100644 index 000000000..1f819a133 --- /dev/null +++ b/results/scraper/fex/3895 @@ -0,0 +1,2 @@ +Rootfs cannot be setted correctly +In FEXConfig, the rootfs is Archlinux,but FEXBash is Ubuntu_22_04 \ No newline at end of file diff --git a/results/scraper/fex/3897 b/results/scraper/fex/3897 new file mode 100644 index 000000000..55ca025a6 --- /dev/null +++ b/results/scraper/fex/3897 @@ -0,0 +1,28 @@ +src/tier0/threadtools.cpp (2036) : Assertion Failed: semaphore creation failed Invalid argument +Environment: Android Busybox Chroot Ubuntu 22.04 +CPU: Snapdragon 8 gen 3 +Rootfs： ArchLinux + +I build fex-emu and don't use the ppa +But Steam can't start. + +Output: +steam@localhost:~$ FEXBash steam +steam.sh[29136]: Running Steam on arch rolling 64-bit +steam.sh[29136]: STEAM_RUNTIME is enabled automatically +setup.sh[29228]: Steam runtime environment up-to-date! +/home/steam/.local/share/Steam/ubuntu12_32/steam-runtime/run.sh: line 85: steam-runtime-identify-library-abi: command not found +run.sh[29244]: steam-runtime-identify-library-abi --ldconfig-paths failed, falling back to ldconfig +steam.sh[29136]: Can't find 'steam-runtime-check-requirements', continuing anyway +tid(29282) burning pthread_key_t == 0 so we never use it +WARNING: setlocale('en_US.UTF-8') failed, using locale: 'C'. International characters may not work. +src/tier0/threadtools.cpp (2439) : Assertion Failed: Function not implemented +src/tier0/threadtools.cpp (2439) : Assertion Failed: Function not implemented +07/26 20:15:20 Init: Installing breakpad exception handler for appid(steam)/version(1.0)/tid(29282) +07/26 20:15:20 Failed writing minidump, nothing to upload. +src/tier0/threadtools.cpp (2036) : Assertion Failed: semaphore creation failed Invalid argument +src/tier0/threadtools.cpp (2036) : Assertion Failed: semaphore creation failed Invalid argument +src/tier0/threadtools.cpp (2439) : Assertion Failed: Function not implemented +src/tier0/threadtools.cpp (2439) : Assertion Failed: Function not implemented +src/tier0/threadtools.cpp (1866) : Thread synchronization object is unuseable +src/tier0/threadtools.cpp (1866) : Thread synchronization object is unuseable \ No newline at end of file diff --git a/results/scraper/fex/3900 b/results/scraper/fex/3900 new file mode 100644 index 000000000..68c2a3dbd --- /dev/null +++ b/results/scraper/fex/3900 @@ -0,0 +1,25 @@ +Steam: webhelper is not responding +**What Game** +steam + +**Describe the bug** +attempting to launch steam (`FEXLoader steam`) results in a window that shows "Steamwebhelper is not responding" + +**To Reproduce** +Steps to reproduce the behavior: +1. Install FEX (Noble PPA armv8.0) with 24.04 rootfs +2. Install steam to the host system +3. start steam with `FEXLoader steam` +4. See error + +**Expected behavior** +Works + + +**System information:** + - OS: Ubuntu 24.04 + - CPU/SoC: Tegra X1 + - Video driver version: 32.3.1 + - RootFS used: Ubuntu 24.04 Official Rootfs + - FEX version: FEX-2407 + - Thunks Enabled: GL and Vulkan \ No newline at end of file diff --git a/results/scraper/fex/3942 b/results/scraper/fex/3942 new file mode 100644 index 000000000..cb2011854 --- /dev/null +++ b/results/scraper/fex/3942 @@ -0,0 +1,13 @@ +Document, Detect, Implement EFAULT handling in syscall handler +Started in #3375 +Continued in #3941 + +Our syscall handlers aren't always robust against EFAULT and in most cases we can't even detect it. + +In #3375 we added memcpy handlers, which adds some overhead and programmer burden towards implementing the EFAULT handling without any guidance towards which syscalls are most likely to hit the problem. + +In #3941 we added validation handlers which resolve if an argument has zero protections, read-only, or read-write capable. This allows us to sprinkle simple LOGMAN handlers around that add zero overhead in release mode, and doesn't place the burden on the programmer to actually implement the EFAULT handling at the start. + +There is still a burden that we need to go through our non-passthrough syscall handlers and add these bound checks to the passed in user-pointers, but this is significantly lower effort. In addition to being lower effort, it will help inform our decisions about which syscalls need EFAULT handling on its arguments, since it'll give an assert message and can be tracked back to a failing syscall. + +An additional task will be implementing an optimized inline memcpy for the handlers introduced in #3375. Currently these are quite slow, since they only copy byte-by-byte. If the memcpy handler is inline then we can detect a PC range for fault detection while still maintaining good speeds. \ No newline at end of file diff --git a/results/scraper/fex/3943 b/results/scraper/fex/3943 new file mode 100644 index 000000000..bef23b8cf --- /dev/null +++ b/results/scraper/fex/3943 @@ -0,0 +1,21 @@ +Work on removing global static initializers +Global static initializers have problems under FEX. They have a couple of problems, mostly centered around memory allocation + +- They can allocate untracked memory upfront that FEX can't control. + - This means it has memory originally allocated through jemalloc before the allocation hooks are setup +- They can register `atexit` handlers that can crash on application close + - This is used to cleanup the memory allocated before FEX can track it + +FEX currently works around these previous problems by leaking all memory allocated on process shutdown and letting the kernel clean it up. + +A major issue that occurs is when the static initializer allocates memory pre-hook, then once the hooks are installed, it allocates new memory through the FEX hooks, having a mix of pre-hook and post-hook memory allocations. On munmap this tracking will get confused and leak memory. + +In the case of mixed-allocation and /not/ leaking, it can result in a crash but it's been a couple years since we enabled the leaking, so I don't quite remember why the crashes come. + +From the on and off work over the past few years, we have removed most static initializers but there are still a handful sprinkled throughout the FEX codebase. + +- ~~A bunch from vixl. With the disassembler disabled we should be able to remove most of these #3962~~ +- ~~One from Thunks.cpp #4021~~ +- One from Config.cpp +- One from IoctlEmulation.cpp +- One from Allocator.cpp \ No newline at end of file diff --git a/results/scraper/fex/3948 b/results/scraper/fex/3948 new file mode 100644 index 000000000..979fa0ab1 --- /dev/null +++ b/results/scraper/fex/3948 @@ -0,0 +1,11 @@ +Cross-process tear free split-lock emulation can't be implemented without kernel support (or TME) +In order to correctly handle split-lock emulation, we need a global mutex. We could easily get this through FEXServer handing a shared page to all FEXInterpreter instances. + +The problem with this is that if a process dies when one of its threads is handling a split-lock (Or cross-16byte boundary atomic) then the mutex will be permanently set. Effectively hanging every running FEXInterpreter process on the system. + +There's no way to work around this in a tear-free fashion and also never have hangs. It /needs/ to be done in the kernel. + +The "alternative" and preferred approach would be if all ARM vendors just support TME, but that's never going to occur. + +As for starting the discussion with the ARM kernel maintainers for getting this supported upstream... + diff --git a/results/scraper/fex/3949 b/results/scraper/fex/3949 new file mode 100644 index 000000000..ce7b85677 --- /dev/null +++ b/results/scraper/fex/3949 @@ -0,0 +1,6 @@ +CI failing due to Sekiro instcountci +https://github.com/FEX-Emu/FEX/blob/6f43c8ffac0558e32cc1654ce9a99150cd29ff4f/unittests/InstructionCountCI/FEXOpt/MultiInst.json#L1026-L1289 + +https://github.com/FEX-Emu/FEX/actions/runs/10370149424/job/28707417989 + +Merge conflict issue or something. Happened on ARMv8.0-a solidrun boards \ No newline at end of file diff --git a/results/scraper/fex/3958 b/results/scraper/fex/3958 new file mode 100644 index 000000000..f4607bcd5 --- /dev/null +++ b/results/scraper/fex/3958 @@ -0,0 +1,2 @@ +Revisit use of static/const/constexpr keywords on variables +We currently apply different, not strictly consistent idioms of these throughout the code base. Instead of derailing PR reviews with discussions on this, let's settle for a few guidelines that should be easy to understand and apply while not introducing performance hazards. diff --git a/results/scraper/fex/3959 b/results/scraper/fex/3959 new file mode 100644 index 000000000..f852bdeca --- /dev/null +++ b/results/scraper/fex/3959 @@ -0,0 +1,70 @@ +libwow64fex.dll FTBS with llvm-mingw +Used toolchain: +[llvm-mingw-20240518-ucrt-ubuntu-20.04-aarch64](https://github.com/mstorsjo/llvm-mingw/releases/tag/20240518) + +How I tried to build: +``` +mkdir build_pe +cd build_pe +export PATH=/path/to/llvm-mingw/bin:$PATH +cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain_mingw.cmake -DENABLE_JEMALLOC=0 -DENABLE_JEMALLOC_GLIBC_ALLOC=0 -DMINGW_TRIPLE=aarch64-w64-mingw32 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_TESTS=False -DENABLE_ASSERTIONS=False .. +make -j$(nproc) wow64fex +``` + + +Problems: + +> /path/to/fex/Source/Windows/Common/CRT/String.cpp:169:21: error: redefinition of '_sscanf_l' +> 169 | DLLEXPORT_FUNC(int, _sscanf_l, (const char* buffer, const char* format, _locale_t locale, ...)) { +> | ^ +> /path/to/llvm-mingw-20240518-ucrt-ubuntu-20.04-aarch64/aarch64-w64-mingw32/include/sec_api/stdio_s.h:160:27: note: previous definition is here +> 160 | __mingw_ovr int __cdecl _sscanf_l(const char *_Src, const char *_Format, _locale_t _Locale, ...) +> | ^ +> /path/to/fex/Source/Windows/Common/CRT/String.cpp:177:39: error: functions that differ only in their return type cannot be overloaded +> 177 | DLLEXPORT_FUNC(const unsigned short*, __pctype_func, (void)) { +> | ~~~~~~~~~~~~~~~ ^ +> /path/to/fex/Source/Windows/Common/CRT/../Priv.h:62:7: note: expanded from macro 'DLLEXPORT_FUNC' +> 62 | Ret Name Args; \ +> | ~~~ ^ +> /path/to/llvm-mingw-20240518-ucrt-ubuntu-20.04-aarch64/aarch64-w64-mingw32/include/ctype.h:29:27: note: previous declaration is here +> 29 | _CRTIMP unsigned short* __pctype_func(void); +> | ~~~~~~~~~~~~~~~ ^ +> /path/to/fex/Source/Windows/Common/CRT/String.cpp:177:1: error: cannot initialize a variable of type 'const unsigned short *(*)()' with an lvalue of type 'unsigned short *()': different return type ('const unsigned short *' vs 'unsigned short *') +> 177 | DLLEXPORT_FUNC(const unsigned short*, __pctype_func, (void)) { +> | ^ ~~~~~~~~~~~~~ +> /path/to/fex/Source/Windows/Common/CRT/../Priv.h:63:8: note: expanded from macro 'DLLEXPORT_FUNC' +> 63 | Ret(*__imp_##Name) Args = Name; \ +> | ^ ~~~~ +> <scratch space>:199:1: note: expanded from here +> 199 | __imp___pctype_func +> | ^ + +... and + +> +> /path/to/fex/Source/Windows/Common/CRT/IO.cpp:281:5: error: redefinition of 'fseeko64' +> 281 | int fseeko64(FILE* File, _off64_t Offset, int Origin) { +> | ^ +> /path/to/llvm-mingw-20240518-ucrt-ubuntu-20.04-aarch64/aarch64-w64-mingw32/include/stdio.h:667:19: note: previous definition is here +> 667 | __mingw_ovr int fseeko64(FILE *_File, _off64_t _Offset, int _Origin) { +> | ^ +> /path/to/fex/Source/Windows/Common/CRT/IO.cpp:286:5: error: redefinition of 'fseeko' +> 286 | int fseeko(FILE* File, _off_t Offset, int Origin) { +> | ^ +> /path/to/llvm-mingw-20240518-ucrt-ubuntu-20.04-aarch64/aarch64-w64-mingw32/include/stdio.h:664:19: note: previous definition is here +> 664 | __mingw_ovr int fseeko(FILE *_File, _off_t _Offset, int _Origin) { +> | ^ +> /path/to/fex/Source/Windows/Common/CRT/IO.cpp:294:10: error: redefinition of 'ftello64' +> 294 | _off64_t ftello64(FILE* File) { +> | ^ +> /path/to/llvm-mingw-20240518-ucrt-ubuntu-20.04-aarch64/aarch64-w64-mingw32/include/stdio.h:673:24: note: previous definition is here +> 673 | __mingw_ovr _off64_t ftello64(FILE *_File) { +> | ^ +> /path/to/fex/Source/Windows/Common/CRT/IO.cpp:300:8: error: redefinition of 'ftello' +> 300 | _off_t ftello(FILE* File) { +> | ^ +> /path/to/llvm-mingw-20240518-ucrt-ubuntu-20.04-aarch64/aarch64-w64-mingw32/include/stdio.h:670:22: note: previous definition is here +> 670 | __mingw_ovr _off_t ftello(FILE *_File) { +> | ^ +> 4 errors generated. +> \ No newline at end of file diff --git a/results/scraper/fex/3987 b/results/scraper/fex/3987 new file mode 100644 index 000000000..f3bff1b79 --- /dev/null +++ b/results/scraper/fex/3987 @@ -0,0 +1,4 @@ +FEXRootFSFetcher does not work in a docker image build step. +Currently, I am unable to run `yes 1 | FEXRootFSFetcher` within a docker build step, as the output is not a TTY. In such a case, the tool attempts to open a graphical interface and fails to run. + +A possible fix would be introducing an environment variable or argument to the program to force it to run in terminal mode. \ No newline at end of file diff --git a/results/scraper/fex/4010 b/results/scraper/fex/4010 new file mode 100644 index 000000000..d7d779ddf --- /dev/null +++ b/results/scraper/fex/4010 @@ -0,0 +1,3 @@ +setlocale error +hi i get an error when i run the FEXBash command : +bash: warning: setlocale: LC_ALL: cannot change locale (fr_FR.UTF-8) \ No newline at end of file diff --git a/results/scraper/fex/4014 b/results/scraper/fex/4014 new file mode 100644 index 000000000..a5a4b7d2a --- /dev/null +++ b/results/scraper/fex/4014 @@ -0,0 +1,4 @@ +Put binfmts in /usr/lib/binfmt.d +It turns out update-binfmts is a debian exclusive piece of infrastructure. For better cross-distro support, install the binfmts to /usr/lib/binfmt.d, which is handled by systemd. + +Problems: the syntax is very different, systemd binfmt isn't as easy to configure as with update-binfmts, might be conflicts if installed in both places and running debian \ No newline at end of file diff --git a/results/scraper/fex/4026 b/results/scraper/fex/4026 new file mode 100644 index 000000000..9c31e1acb --- /dev/null +++ b/results/scraper/fex/4026 @@ -0,0 +1,4 @@ +Support scaling cyclecounter dynamically +Today FEX hardcodes a left shift of 7 for any cycle counter that is below 1Ghz. This was mostly done out of laziness because it covered all platforms I cared about at the time, and ARMv8.6/ARMv9.1 mandates a 1Ghz cycle counter to be compliant. + +We should instead dynamically scale the cycle counter since there are platforms that have a higher frequency counter. Which apparently causes issues with libpsm2? We are still likely to typically hit scale factor of 7 or 6, so it won't change dramatically. \ No newline at end of file diff --git a/results/scraper/fex/4065 b/results/scraper/fex/4065 new file mode 100644 index 000000000..acb9bd76c --- /dev/null +++ b/results/scraper/fex/4065 @@ -0,0 +1,16 @@ +Issue with executing steamcmd +I installed FEX using the quick start command in the read.me, I also installed SteamCMD and checked that the files are there. However if I try executing steamcmd.sh I get the following error: + +``` +Invalid or Unsupported elf file. +This is likely due to a misconfigured x86-64 RootFS +Current RootFS path set to '' +RootFS path doesn't exist. This is required on AArch64 hosts +Use FEXRootFSFetcher to download a RootFS +``` + +I tried both using the rootfs as extracted and "as is" using FEXRootFSFetcher. I use Ubuntu 22.04.4 on a free tier oracle server, if this helps. +The content of the Config.json file is : `{"Config":{"RootFS":"Ubuntu_22_04"}}` +There is also a folder `/home/ubuntu/.fex-emu/RootFS/Ubuntu_22_04` with contents that look like an Ubuntu image. + +Thank you for any help. \ No newline at end of file diff --git a/results/scraper/fex/4083 b/results/scraper/fex/4083 new file mode 100644 index 000000000..164841778 --- /dev/null +++ b/results/scraper/fex/4083 @@ -0,0 +1,4 @@ +Vulkan thunk symbols should be updated soon +There's been a decent number of extensions that have landed so we should update the headers and symbols. Including some extensions that drivers and d3d layers will be using. + +Probably should do this soon-ish. \ No newline at end of file diff --git a/results/scraper/fex/4084 b/results/scraper/fex/4084 new file mode 100644 index 000000000..a7037c95e --- /dev/null +++ b/results/scraper/fex/4084 @@ -0,0 +1,32 @@ +Ara: History Untold: Hang or Close +**What Game** +Ara: History Untold +https://store.steampowered.com/app/2021880/Ara_History_Untold/ + +**Describe the bug** +In a release build, FEX hangs in `HandleThreadDeletion` in a mutex. In a debug build the game seems to early exit. + +**To Reproduce** +Steps to reproduce the behavior: +1. Start the game +2. Click `Continue` for unknown GPU +3. Watch the game hang or close + +**Expected behavior** +Expect to get in-game. + +**System information:** + - OS: Ubuntu 24.04 LTS + - CPU/SoC: Snapdragon X Elite + - Video driver version: Mesa 24.2.0 (git-22fafc9824) + - RootFS used: Ubuntu 24.04 + - FEX version: FEX-2409-127-g3c3e7e9 + - Thunks Enabled: No + +**Additional context** + - Is this an x86 or x86-64 game: x86-64 + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: No + - If Yes, What is your Vulkan driver: + +`[ASSERT][6543.472828618][12916.12919] Signals in dispatcher have unsynchronized context` in Debug build diff --git a/results/scraper/fex/4087 b/results/scraper/fex/4087 new file mode 100644 index 000000000..b959aff9b --- /dev/null +++ b/results/scraper/fex/4087 @@ -0,0 +1,15 @@ +Couldn't download rootfs list from the server. +I'm trying to use FEXRootFSFetcher but I'm getting this error: + +``` +Using default interface naming scheme 'v255'. +INFO <sommelier-scope-timer.cc:30> ~ScopeTimer: configure event loop: 0.00027375 seconds +INFO <sommelier-scope-timer.cc:30> ~ScopeTimer: drm device: 0.0185686 seconds +INFO <sommelier-scope-timer.cc:30> ~ScopeTimer: connect display: 1.7583e-05 seconds +INFO <sommelier-scope-timer.cc:30> ~ScopeTimer: client create: 1.3125e-05 seconds +INFO <sommelier-scope-timer.cc:30> ~ScopeTimer: display implementation: 4.708e-06 seconds +INFO <sommelier-scope-timer.cc:30> ~ScopeTimer: spawn xwayland: 0.000207125 seconds +Couldn't download rootfs list from the server. Try again in a minute or report on the fex-emu issue tracker. +"FEXRootFSFetcher" process exited with status code: 255 +FATAL <sommelier.cc:2960> sl_handle_x_connection_event: got error or hangup (mask 5) on X connection, exiting +``` \ No newline at end of file diff --git a/results/scraper/fex/4104 b/results/scraper/fex/4104 new file mode 100644 index 000000000..4b645db69 --- /dev/null +++ b/results/scraper/fex/4104 @@ -0,0 +1,33 @@ +Fix fsgsbase on hostrunner +Once https://github.com/herumi/xbyak/pull/193 is merged, rebase xbyak on latest. + +Then make sure to save and restore fs/gs in the hostrunner. +This will let our unittests use wrfsbase without breaking host TLS, since it can be restored. + +Example for just fs, but should include gs also: +```diff +diff --git a/Source/Tools/TestHarnessRunner/TestHarnessRunner/HostRunner.cpp b/Source/Tools/TestHarnessRunner/TestHarnessRunner/HostRunner.cpp +index 0e9b88cca..9a816ccac 100644 +--- a/Source/Tools/TestHarnessRunner/TestHarnessRunner/HostRunner.cpp ++++ b/Source/Tools/TestHarnessRunner/TestHarnessRunner/HostRunner.cpp +@@ -51,7 +51,8 @@ public: + push(r13); + push(r14); + push(r15); +- sub(rsp, 8); ++ rdfsbase(rbx); ++ push(rbx); + + // Save this stack pointer so we can cleanly shutdown the emulation with a long jump + // regardless of where we were in the stack +@@ -103,8 +104,8 @@ public: + + ThreadStopHandlerAddress = getCurr<uint64_t>(); + +- add(rsp, 8); +- ++ pop(rbx); ++ wrfsbase(rbx); + pop(r15); + pop(r14); +``` \ No newline at end of file diff --git a/results/scraper/fex/4111 b/results/scraper/fex/4111 new file mode 100644 index 000000000..887956e31 --- /dev/null +++ b/results/scraper/fex/4111 @@ -0,0 +1,32 @@ +[Steam]: [Segfault on Ubuntu 24.04, PPA inside Distrobox on postmarketOS] +**What Game** +Steam client + +**Describe the bug** +It downloads and installs the runtime, then the Steam updater window briefly appears before it crashes with a segfault. + +**To Reproduce** +Steps to reproduce the behavior: +1. FEXInterpreter steam + +**Expected behavior** +Steam window (login prompt) appears + +**Screenshots and Video** +If applicable, add screenshots and video to help explain your problem. + +**System information:** + - OS: [Ubuntu 24.04 root/init enabled Distrobox image running on postmarketOS Edge] + - CPU/SoC: [Qualcomm Snapdragon SDM845 (OnePlus 6T oneplus-fajita] + - Video driver version: [freedreno mesa 24.0.9-ubuntu0.1] + - RootFS used: [Ubuntu 24.04 Official Rootfs] + - FEX version: (FEXGetConfig --version) [FEX-2410] + - Thunks Enabled: [Not sure] + +**Additional context** + - Is this an x86 or x86-64 game: [x86 AFAIK] + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: [Untested] + - Is this a Vulkan game: [Not sure] + - If Yes, What is your Vulkan driver: Turnip Adreno 630 + +Add any other context about the problem here. \ No newline at end of file diff --git a/results/scraper/fex/4112 b/results/scraper/fex/4112 new file mode 100644 index 000000000..f0f2632d5 --- /dev/null +++ b/results/scraper/fex/4112 @@ -0,0 +1,59 @@ +[Compilation Error] Build Thunklibs fails with LLVM-19 +# Description + +Building main trunk after upgrading to LLVM-19 is failing with this log: +``` +% ninja +[0/2] Re-checking globbed directories... +[1/67] Building CXX object ThunkLibs/Generator/CMakeFiles/thunkgenlib.dir/analysis.cpp.o +FAILED: ThunkLibs/Generator/CMakeFiles/thunkgenlib.dir/analysis.cpp.o +/usr/bin/clang++ -DFEX_HAS_PRESERVE_ALL_ATTR=1 -DFEX_PRESERVE_ALL_ATTR="__attribute__((preserve_all))" -DGDB_SYMBOLS_ENABLED=1 -DGLOBAL_DATA_DIRECTORY=\"/usr/share/fex-emu/\" -D_M_ARM_64=1 -I/home/ektor5/FEX/build/ThunkLibs/Generator -I/home/ektor5/FEX/ThunkLibs/Generator -I/home/ektor5/FEX/External/robin-map/include -I/home/ektor5/FEX/External/tiny-json -I/home/ektor5/FEX/Source -I/home/ektor5/FEX/build/Source -I/home/ektor5/FEX/External/fmt/include -isystem /usr/lib/llvm-19/include -O3 -DNDEBUG -fomit-frame-pointer -std=gnu++20 -flto=thin -fPIC -Wno-trigraphs -fdiagnostics-color=always -fcolor-diagnostics -Wno-deprecated-enum-enum-conversion -Wall -MD -MT ThunkLibs/Generator/CMakeFiles/thunkgenlib.dir/analysis.cpp.o -MF ThunkLibs/Generator/CMakeFiles/thunkgenlib.dir/analysis.cpp.o.d -o ThunkLibs/Generator/CMakeFiles/thunkgenlib.dir/analysis.cpp.o -c /home/ektor5/FEX/ThunkLibs/Generator/analysis.cpp +/home/ektor5/FEX/ThunkLibs/Generator/analysis.cpp:248:36: error: no member named 'getTypeAsWritten' in 'clang::ClassTemplateSpecializationDecl' + 248 | throw report_error(decl->getTypeAsWritten()->getTypeLoc().getAs<clang::TemplateSpecializationTypeLoc>().getArgLoc(1).getLocation(), + | ~~~~ ^ +/home/ektor5/FEX/ThunkLibs/Generator/analysis.cpp:257:36: error: no member named 'getTypeAsWritten' in 'clang::ClassTemplateSpecializationDecl' + 257 | throw report_error(decl->getTypeAsWritten()->getTypeLoc().getAs<clang::TemplateSpecializationTypeLoc>().getArgLoc(2).getLocation(), + | ~~~~ ^ +/home/ektor5/FEX/ThunkLibs/Generator/analysis.cpp:300:17: error: no member named 'getTypeAsWritten' in 'clang::ClassTemplateSpecializationDecl' + 300 | decl->getTypeAsWritten()->getTypeLoc().castAs<clang::TemplateSpecializationTypeLoc>().getArgLoc(0).getLocation(); + | ~~~~ ^ +/home/ektor5/FEX/ThunkLibs/Generator/analysis.cpp:302:18: warning: variable 'emitted_function' set but not used [-Wunused-but-set-variable] + 302 | if (auto emitted_function = llvm::dyn_cast<clang::FunctionDecl>(template_args[0].getAsDecl())) { + | ^ +/home/ektor5/FEX/ThunkLibs/Generator/analysis.cpp:337:17: error: no member named 'getTypeAsWritten' in 'clang::ClassTemplateSpecializationDecl' + 337 | decl->getTypeAsWritten()->getTypeLoc().castAs<clang::TemplateSpecializationTypeLoc>().getArgLoc(0).getLocation(); + | ~~~~ ^ +1 warning and 4 errors generated. +ninja: build stopped: subcommand failed. +``` + +# Environment + +Machine: Snapdragon X Elite X1E80100 ARM64 +Kernel: 6.11.0-rc6-gf60a0fc0c2a7 arch: aarch64 bits: 64 +Distro: Debian Sid +Compiler: Clang +``` +Debian clang version 19.1.1 (1) +Target: aarch64-unknown-linux-gnu +Thread model: posix +InstalledDir: /usr/lib/llvm-19/bin +``` + +FEX Build Configuration: +``` +CC=clang CXX=clang++ cmake \ + -DCMAKE_INSTALL_PREFIX=/usr \ + -DCMAKE_BUILD_TYPE=Release \ + -DUSE_LINKER=lld \ + -DENABLE_LTO=True \ + -DBUILD_TESTS=False \ + -DENABLE_ASSERTIONS=False \ + -DBUILD_THUNKS=True \ + -G Ninja .. +``` + +# Other Information + +Removed `build` directory completely and compiled from scratch. +Compilation works fine with LLVM-18 or disabling Thunks. \ No newline at end of file diff --git a/results/scraper/fex/4114 b/results/scraper/fex/4114 new file mode 100644 index 000000000..0740b91ae --- /dev/null +++ b/results/scraper/fex/4114 @@ -0,0 +1,24 @@ +32-bit games that use EVDEV for gamepad input are broken +After months of knowing that gamepad input was flaky for 32-bit processes, I finally spent some time looking at the problem. + +Initially I thought it was either a joydev or evdev ioctl issue, since a lot of those ioctls are opaque and the kernel has compat handlers for them. Going through each of the ioctls though, the compat handlers are actually just in-place for big-endian byte swapping of 64-bit words, so behaviour matches on little endian machines. + +I then tracked back to evdev read/write syscalls to see what happens there, and this is where the problem lies. +Readers and writers for evdev events happen in `drivers/input/input-compat.c` with three functions: +- input_event_from_user - Handles write events that aren't force feedback...? +- input_event_to_user - Handles input events (read events) +- input_ff_effect_from_user - Handles force-feedback events + +These three functions will check if the process running is a 32-bit process and will handle the data as if it were `struct input_event` or `struct input_event_compat` depending. This struct has a different layout depending on 32-bit or 64-bit because they decided to stick the timestamp at the start of the struct and the type, code, value elements after the timestamp. Completely borking the information because the timestamp is different sized. + +Force feedback also has a different layout, but it might also randomly work because the data that changes is at the end? Haven't looked too closely at it. + +There's no way to have FEX correctly work around this problem today other than categorizing FDs somehow to know it is an evdev FD, and fixing it up in our 32-bit read/write syscall handlers. + +#4106 worked around the issue by adding support for a prctl in their kernel that forces the application to use the compat path, which while it works, it's only a bandage shortterm until we can get something permanent in place. As this only solves the problem for 32-bit evdev/input events, doesn't handle potential other devices that could encounter the same issues with read, write, lseek, etc. + +Ideally the upstream Linux kernel would allow us to land our 32-bit compat path patches, but that won't ever happen. https://lore.kernel.org/all/20210518090658.9519-1-amanieu@gmail.com/ + +When I get a moment I'll add read/write to our wiki about 32-bit problems. https://wiki.fex-emu.com/index.php/Development:32Bit_Syscall_Woes + +I don't have any solutions here, just tracking the issue. diff --git a/results/scraper/fex/4115 b/results/scraper/fex/4115 new file mode 100644 index 000000000..f8fc3db1c --- /dev/null +++ b/results/scraper/fex/4115 @@ -0,0 +1,22 @@ +Installation issues +I am on Asahi Linux (Fedora) and following the [installation guide](https://wiki.fex-emu.com/index.php/Development:Setting_up_FEX). During build configuration I get the following error message: +``` +CMake Error at Source/Tools/CMakeLists.txt:7 (find_package): + By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has + asked CMake to find a package configuration file provided by "Qt5", but + CMake did not find one. + + Could not find a package configuration file provided by "Qt5" with any of + the following names: + + Qt5Config.cmake + qt5-config.cmake + + Add the installation prefix of "Qt5" to CMAKE_PREFIX_PATH or set "Qt5_DIR" + to a directory containing one of the above files. If "Qt5" provides a + separate development package or SDK, be sure it has been installed. + + +-- Configuring incomplete, errors occurred! +``` +I am at current HEAD 389ad737 and I've installed all the Fedora dependencies. \ No newline at end of file diff --git a/results/scraper/fex/412 b/results/scraper/fex/412 new file mode 100644 index 000000000..d41bc082b --- /dev/null +++ b/results/scraper/fex/412 @@ -0,0 +1,4 @@ +Interpreter Float conversion doesn't ensure host flag behaviour +Brought up in #408, Interpreter float conversion ops won't use the host flag for rounding mode, but instead just truncate (As per C/C++ spec). + +We need a unit test to ensure correct rounding behaviour here. \ No newline at end of file diff --git a/results/scraper/fex/4120 b/results/scraper/fex/4120 new file mode 100644 index 000000000..8e40046e2 --- /dev/null +++ b/results/scraper/fex/4120 @@ -0,0 +1,51 @@ +Preparation plan for increasing minimum requirements to require FEAT_FLAGM/ARMv8.4-a +- **Note:** This is will likely happen in the middle of 2025. + +Currently FEX supports back to ARMv8.0-a, which has been a maintenance burden that can be both frustrating and slow to support. Once we increase minspec to FEAT_FLAGM, this effectively increases our minspec to ARMv8.4-a. So choosing ARMv8.4-a is actually the sane option. This would basically increase FEX's minimum CPU requirements to support hardware released in 2019-2021, so at least four year old hardware by time this change actually ends up in FEX. + +**Unique codepaths in FEX for things below v8.4:** +- Flags handling + - FEAT_FLAGM adds support for accelerating x86 flags emulation +- FEAT_LSE - Atomic memory operations + - Everything uses load-exclusive, store-exclusive on v8.0. + - Complicates our unaligned atomic handling +- FEAT_LRCPC and FEAT_LRCPC2 + - Accelerates x86 memory model (even if it isn't very good) + - Changes load/store atomic in to equivalent LRCPC instructions +- FEAT_LSE2 + - Supports unaligned atomics inside a 16-byte granularity + - Just like FEAT_LSE improved atomics, this improves unaligned atomics + - Can reduce complications in FEX's unaligned atomic handlers +- A few misc things. + +Performance wise, without these extensions x86 emulation is either slow (atomics) or buggy (TSO emulation disabled) so supporting things older aren't fundamentally interesting and causes us maintenance and financial (CI) burden. + +Performance considerations show that while some of this deprecated hardware can play lighter games, the performance for anything remotely heavily isn't very interesting. + +**What hardware would this change cause FEX to no longer support?** +- CPUs: + - ARM: Cortex-A57 through Cortex-A78 + +- SoCs: + - Apple: Nothing (FEX only supports devices with M1 or newer, which is v8.4-a or newer) + - Qualcomm mobile: Snapdragon 888 and older + - Qualcomm Compute: 8cx Gen 3 (Latest generation before Oryon/X1E) + - Samsung: Exynos 2100 and older + - NVIDIA: Orin and older (Thor in 2025 will be first Jetson. Grace is fine) + - Rockchip: Everything + - Raspberry Pi: Everything + - Amlogic: Everything + - Ampere: Altra + +**What hardware will still be available to use FEX with after this change?** +- Apple: All "Apple Silicon" M series +- Ampere: AmpereOne +- NVIDIA: Thor (2025), and Grace +- Snapdragon mobile: Snapdragon 8 Gen 1 and newer +- Snapdragon Compute: X Elite +- Samsung: Exynos 2200 and newer +- Radxa Orion O6 +- Rockchip: RK3688 (Will be shipping a Cortex-A7xx CPU in likely 2025) +- Amlogic: Nothing today +- Pi: Nothing today + diff --git a/results/scraper/fex/4121 b/results/scraper/fex/4121 new file mode 100644 index 000000000..e9eddd438 --- /dev/null +++ b/results/scraper/fex/4121 @@ -0,0 +1,5 @@ +FEXConfig: Block size can't be modified with keyboard + + +Means making large changes impossible and I've fallen back to editing Config.json directly. +No idea what the problem is. QT garbage? \ No newline at end of file diff --git a/results/scraper/fex/4123 b/results/scraper/fex/4123 new file mode 100644 index 000000000..272e0816a --- /dev/null +++ b/results/scraper/fex/4123 @@ -0,0 +1,6 @@ +{V,}PSHUF{L,H}W implementation can be unified +Currently the AVX128 implementation does a InsElement dance, the SSE and MMX versions are slightly more efficient in that it understands broadcast and a TBL implementation. + +These three versions can be unified, which will immediately improve the perf of the AVX128 implementation. + +Related to #3785 \ No newline at end of file diff --git a/results/scraper/fex/4124 b/results/scraper/fex/4124 new file mode 100644 index 000000000..6411e86ff --- /dev/null +++ b/results/scraper/fex/4124 @@ -0,0 +1,2 @@ +Fix classification script to work around qualcomm disabling SVE on their chips +Causes things compiled through AUR or native with default classification to SIGILL at the start. Need to check for enabled features through cpuinfo or cpuid flags and work around that. diff --git a/results/scraper/fex/4126 b/results/scraper/fex/4126 new file mode 100644 index 000000000..1aaf1d61d --- /dev/null +++ b/results/scraper/fex/4126 @@ -0,0 +1,7 @@ +80-bit x87 Loadstores can use SVE masked loadstores +Currently we need to split these in to a 64-bit and 16-bit loadstore operations. +With SVE and masking loadstores this can be changed in to one. +First step would probably be to convert current operations that need to do 80-bit loadstores to synthesize the required predicate and then to the loadstore. +Step after that would be to add predicate registers to our RA allocator so we can cache the 80-bit predicate across multiple loadstores (like fnsave, frstor would want). + +Purely a performance optimization around x87 80-bit loadstores. \ No newline at end of file diff --git a/results/scraper/fex/413 b/results/scraper/fex/413 new file mode 100644 index 000000000..f901cec32 --- /dev/null +++ b/results/scraper/fex/413 @@ -0,0 +1,3 @@ +Float to integer overflow doesn't match behaviour +Brought up in #408, we don't handle float conversion overflow correctly between x86 host and ARM. +We need a unit test to ensure correct behaviour here. \ No newline at end of file diff --git a/results/scraper/fex/4131 b/results/scraper/fex/4131 new file mode 100644 index 000000000..a192d8bb2 --- /dev/null +++ b/results/scraper/fex/4131 @@ -0,0 +1,13 @@ +Bear's Restaurant has race condition with deferred signal handling +[Bear's Restaurant](https://store.steampowered.com/app/1687550/Bears_Restaurant/) has a race condition with FEX's deferred signal handling. Its [game engine](https://ebitengine.org/) is based on golang, which sends SIGURG /very/ quickly for doing preemption to ensure thread fairness. + +A couple of things to fix in FEX's deferred signal handling. +- If its not a realtime signal, then these shouldn't be queued and instead just set in a mask of available signals. + - Linux doesn't queue non-RT signals, expecting many non-RT signals to be lost rather than queued +- FEX should block the `sa_mask` in the signal handler of the signal getting deferred, to ensure it doesn't receive anymore of that signal. + - This would ensure FEX doesn't overrun its small signal queue, which can typically result in crashes. + - Make sure to restore signal mask once actually handling the signal + +I don't have time to implement these fixes right now but I needed a tracking issue to remember it. + +I originally wanted to test this engine to see it break under Asahi Linux, but apparently it uses a new enough version of golang that it no longer hits the VDSO bug, might need to try an older game using this engine to see the Asahi breakage. \ No newline at end of file diff --git a/results/scraper/fex/4133 b/results/scraper/fex/4133 new file mode 100644 index 000000000..6092f9466 --- /dev/null +++ b/results/scraper/fex/4133 @@ -0,0 +1,29 @@ +Failed to load driver: vc4 (Raspberry Pi 5) +Hi, + +I'm running FEX 2410 on a Raspberry Pi 5 with Raspberry Pi OS Lite using the preconfigured Ubuntu 24.04 as RootFS. I've been getting this error when running x86_64 Carla : + +``` +Carla 2.5.9 started, status: + Python version: 3.12.3 + Qt version: 5.15.13 + PyQt version: 5.15.10 + Binary dir: /opt/carla-2.5.9-x86_64/lib/carla + Resources dir: /opt/carla-2.5.9-x86_64/share/carla/resources +did not find extension DRI_IMAGE_DRIVER version 1 +did not find extension DRI_Mesa version 1 +failed to load driver: vc4 +did not find extension DRI_Mesa version 1 +failed to load driver: vc4 +Cannot connect to server socket err = No such file or directory +Cannot connect to server request channel +jack server is not running or cannot be started +JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock +JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock +Frontend pixel ratio is 1.0 +libjack.so.0 loaded successfully! +``` + +Some plugins I'm using with Carla need some video acceleration to run properly, I'm guessing it has to do with the "failed to load driver" part (though I have no way to compare). I've done some digging on Linux video drivers, but this goes beyond my abilities since there's no vc4 drivers available that I could install on the RootFS. + +I've been playing around with this for some time, is this known behavior I never noticed, did something change, or am I looking at the wrong thing ? \ No newline at end of file diff --git a/results/scraper/fex/4148 b/results/scraper/fex/4148 new file mode 100644 index 000000000..9b63ee483 --- /dev/null +++ b/results/scraper/fex/4148 @@ -0,0 +1,47 @@ +Regression from 2408 to 2409 (segfault on running anything) +Device: + +``` +OS: Ubuntu noble 24.04 aarch64 +Host: Nintendo Switch (2017) +Kernel: Linux 4.9.140-l4t +Uptime: 1 hour, 18 mins +Packages: 3276 (dpkg), 6 (flatpak) +Shell: bash 5.2.21 +DE: KDE Plasma 5.27.11 +WM: KWin (X11) +WM Theme: Breeze +Theme: Breeze (Light) [Qt], Breeze [GTK2/3/4] +Icons: Breeze [Qt], breeze-dark [GTK2/3/4] +Font: Noto Sans (10pt) [Qt], Noto Sans (10pt) [GTK2/3/4] +Cursor: Breeze (24px) +Terminal: /dev/pts/3 +CPU: icosa (4) @ 2.09 GHz +GPU: NVIDIA Tegra X1 (nvgpu) [Integrated] +Memory: 1.70 GiB / 3.90 GiB (44%) +Swap: 0 B / 3.00 GiB (0%) +Disk (/): 59.42 GiB / 122.94 GiB (48%) - ext4 +Battery: 100% [AC Connected] +Locale: C.UTF-8 +``` + +Starting with 2409 (build from source or the Ubuntu PPA) I get the following error on running any command (such as FEXBash) + +``` +Illegal instruction (core dumped) +``` + +This is not an issue on 2408 or previous versions in my testing. + +Happy to bisect further if any developer has insight in which change likely could be the cause of this issue + +my build (release) only gives the following in gdb bt + +``` +#0 0x000000555576c904 in FEX::FetchHostFeatures() () +#1 0x0000005555630dec in main () +``` + +so maybe it has something to do with https://github.com/FEX-Emu/FEX/commit/941b065da60494b324aa4efc0d35ab007aa272a4 which was introduced in 2409? + +CC: @Azkali @bylaws \ No newline at end of file diff --git a/results/scraper/fex/4150 b/results/scraper/fex/4150 new file mode 100644 index 000000000..3afff0262 --- /dev/null +++ b/results/scraper/fex/4150 @@ -0,0 +1,12 @@ +FEX tests may generate unwanted instruction form +I am not 100% sure if I am right here, so apologies if I am not. +I was looking at test `OpSize/66_D6.asm` which has the instruction: +`movq xmm0, xmm2` +This on NASM generates the (probably unintended) form: +`movq xmm0, xmm2 ; +0 = f3 0f 7e c2` (https://godbolt.org/z/ebWchEcbb) +While I assume the one that the test focuses on testing is the form: +`movq xmm0, xmm2 ; +0 = 66 0f d6 d0` + +I assume this doesn't cause any real problems, but I thought you might want to know that the test doesn't test the reg/reg form of the D6 opcode (if I am right). + +This may or may not also happen on other tests that have both a xmm/xmm128 and a xmm128/xmm form where NASM compiles them to the unintended form. \ No newline at end of file diff --git a/results/scraper/fex/4151 b/results/scraper/fex/4151 new file mode 100644 index 000000000..cce4e8f23 --- /dev/null +++ b/results/scraper/fex/4151 @@ -0,0 +1,7 @@ +FEX-Emu: Planned CI outage Nov/6 - Nov/15 +FEX-Emu CI infrastructure is going down between these dates as they get moved to a new data center. + +* Planned dates: Nov/6 to Nov/12. +* Extenuating circumstances may push this to Nov/15. + +This is a tracking issue for tracking any status changes. \ No newline at end of file diff --git a/results/scraper/fex/4152 b/results/scraper/fex/4152 new file mode 100644 index 000000000..3f48bce4f --- /dev/null +++ b/results/scraper/fex/4152 @@ -0,0 +1,4 @@ +Support longjump-style faultable code segments +This will be necessary for sigill handling in the frontend decoder and /maybe/ can be used for EFAULT handling in the syscall emulation. + +Basically longjump, but with signal causing the long jump. I saw some game that would have benefitted from this a while ago, but I don't remember what it was. \ No newline at end of file diff --git a/results/scraper/fex/4155 b/results/scraper/fex/4155 new file mode 100644 index 000000000..ca9715de8 --- /dev/null +++ b/results/scraper/fex/4155 @@ -0,0 +1,3 @@ +FEXServer failure to connect log failing to go to stderr + +In this completely fatal situation, these error messages should be going to stderr, but they are going to -1. Should get fixed. \ No newline at end of file diff --git a/results/scraper/fex/4156 b/results/scraper/fex/4156 new file mode 100644 index 000000000..5cc8f9a6e --- /dev/null +++ b/results/scraper/fex/4156 @@ -0,0 +1,11 @@ +FEX unable to work - can't set rootFS, trying to rerun the script gives PPA failed to install +I'm trying to get steamCMD running so I can easily manage a server software that's only x86 compatible. After setting up FEX, I am certainly sure that I configured rootFS from the installer. yet I can't run SteamCMD, as it reports +`Invalid or Unsupported elf file. +This is likely due to a misconfigured x86-64 RootFS +Current RootFS path set to '' +RootFS path doesn't exist. This is required on AArch64 hosts +Use FEXRootFSFetcher to download a RootFS` +Rerunning the installer gives +`PPA failed to install +apt sources failed to update. Not continuing` +PPA Status reports as installed in the download log btw. I'm unsure what to do \ No newline at end of file diff --git a/results/scraper/fex/4184 b/results/scraper/fex/4184 new file mode 100644 index 000000000..950be35f6 --- /dev/null +++ b/results/scraper/fex/4184 @@ -0,0 +1,4 @@ +FEXServer auto-shutdown regression +FEXServer is supposed to exit automatically (with a 10s delay) if no more FEXInterpreter processes are running. Since d761fc44f4a694b205519e0f1fe36eea7de789f3, this doesn't happen anymore: FEXServer permanently stays open. + +@asahilina Any idea what's happening? diff --git a/results/scraper/fex/4191 b/results/scraper/fex/4191 new file mode 100644 index 000000000..dfa6f6e62 --- /dev/null +++ b/results/scraper/fex/4191 @@ -0,0 +1,12 @@ +Double check x87 precision correctness +x86 manual had a couple statements that caught my eye. + + +> The Precision control (PC) field comprises bits [9:8] of the x87 control word (“x87 Control Word Register (FCW)” on page 292). This field specifies the precision of floating-point calculations for the FADDx, FSUBx, FMULx, FDIVx, and FSQRT instructions, as shown in Table 6-11. + +I think we modify precision on more than those instructions listed. Might need to check that. + +Also: +> x87 computations are carried out in double-extended-precision format, so that the transcendental functions provide results accurate to within one unit in the last place (ulp) for each of the floating- point data types. + +Might want to double check that we have the transcendental accuracy correct. \ No newline at end of file diff --git a/results/scraper/fex/4192 b/results/scraper/fex/4192 new file mode 100644 index 000000000..d7d1b9682 --- /dev/null +++ b/results/scraper/fex/4192 @@ -0,0 +1,6 @@ +x86 LXC guests on ARM64? +Hello, + +It would be really cool to be able to be able to migrate and run entire unmodified amd64 LXC guest systems on ARM. I do not see this mentioned in issues so far. But it seems you already have most of the functionality to make this possible, even relying on a full x86 rootfs to be present, one step from there to launching that root FS as a full guest system. What remains is some kernel cgroup/namespaces stuff, and starting emulation with the "init" process which would then start the rest of its services, not a particular single app. + +Would you consider adding this? Or maybe it is possible already? \ No newline at end of file diff --git a/results/scraper/fex/4196 b/results/scraper/fex/4196 new file mode 100644 index 000000000..94b8cc6bc --- /dev/null +++ b/results/scraper/fex/4196 @@ -0,0 +1,33 @@ +Half-Life 2: e53f3969e9cc causes hitching under certain `fps_max` conditions +**What Game** +[Half-Life 2](https://store.steampowered.com/app/220) + +**Describe the bug** +Half-Life 2 suffers from extreme hitching and instability - even at menus - on Apple Silicon machines. Notably, this _only_ occurs when the engine is actively limiting frames via `fps_max`. It does not occur when `fps_max 0`, nor does it occur when the achievable framerate is lower than the `fps_max` limit. Of course, this is is almost never the case on these machines ;) + +This is most obvious in certain menu maps, as well as while playing. I have bisected this down to e53f3969e9cc. Reverting back to the old `pause` behaviour clears this issue. + +**To Reproduce** +Steps to reproduce the behavior: +1. Fire up Half-Life 2 +2. Go to Episode 2 +3. Observe the menu system hitching +4. Fire up an Episode 2 save game +5. Observe the game hitching to the point of unplayability + +**Expected behavior** +The game should run without hitching. + +**System information:** + - OS: Gentoo Linux + - CPU/SoC: Apple M2 Max (also repros on M2, M2 Pro, and M1 Pro) + - Video driver version: [Mesa `asahi-20241204`](https://gitlab.freedesktop.org/asahi/mesa/-/tags/asahi-20241204) + - RootFS used: @WhatAmISupposedToPutHere/fex-rootfs (Minimal Gentoo x86 with asahi mesa overlayed) + - FEX version: Prints nothing (???), but it's upstream FEX-2410 with no patches. + - Thunks Enabled: Yes + +**Additional context** + - Is this an x86 or x86-64 game: x86 + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: Via Source's DXVK integration + - If Yes, What is your Vulkan driver: Honeykrisp. Behaviour is reproducible with both the DXVK and toGL pipelines. \ No newline at end of file diff --git a/results/scraper/fex/4198 b/results/scraper/fex/4198 new file mode 100644 index 000000000..d8e723a30 --- /dev/null +++ b/results/scraper/fex/4198 @@ -0,0 +1,40 @@ +FEXCore: steam hangs at startup with one thread at 100% +Howdy! + +I am running Steam with FEX-2412 on muvm ~0.1.4~ 0.1.3-r1 on M1 Max. + +Steam keeps hanging at startup with one thread running constantly at 100%. I was bisecting the release till merge commit 41c8731443a08141e09ce9941921ca792bdf0bb4 (https://github.com/FEX-Emu/FEX/pull/4188). 9febddefa3b8f8334e3f8d8b9f7cb979358b48c8 works well. + +```bash +/usr/bin/muvm -- FEXInterpreter /home/n3ph/.local/share/fex-steam/steam-launcher/bin_steam.sh -cef-force-occlusion -cef-force-opaque-backgrounds +Using default interface naming scheme 'v255'. +Configuration file /usr/lib/udev/rules.d/93-macsmc-battery-charge-control.rules is marked executable. Please remove executable permission bits. Proceeding anyway. +The XKEYBOARD keymap compiler (xkbcomp) reports: +> Warning: Unsupported maximum keycode 708, clipping. +> X11 cannot support keycodes above 255. +> Warning: Could not resolve keysym XF86KbdInputAssistPrevgrou +> Warning: Could not resolve keysym XF86KbdInputAssistNextgrou +Errors from xkbcomp are not fatal to the X server +/home/n3ph/.local/share/Steam/steam.sh: line 190: DISTRIB_RELEASE: unbound variable +/home/n3ph/.local/share/Steam/steam.sh: line 190: DISTRIB_RELEASE: unbound variable +steam.sh[291]: Running Steam on gentoo 64-bit +/home/n3ph/.local/share/Steam/steam.sh: line 190: DISTRIB_RELEASE: unbound variable +steam.sh[291]: STEAM_RUNTIME is enabled automatically +setup.sh[367]: Steam runtime environment up-to-date! +/home/n3ph/.local/share/Steam/ubuntu12_32/steam-runtime/run.sh: line 85: steam-runtime-identify-library-abi: command not found +run.sh[381]: steam-runtime-identify-library-abi --ldconfig-paths failed, falling back to ldconfig +steam.sh[291]: Couldn't find /home/n3ph/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/bin/srt-logger, logging to console-linux.txt +steam.sh[291]: Can't find 'steam-runtime-check-requirements', continuing anyway +WARNING: setlocale('en_US.UTF-8') failed, using locale: 'C'. International characters may not work. +[2024-12-08 00:44:43] Startup - updater built Jul 16 2024 23:21:18 +[2024-12-08 00:44:43] Startup - Steam Client launched with: '/home/n3ph/.local/share/Steam/ubuntu12_32/steam' '-cef-force-occlusion' '-cef-force-opaque-backgrounds' +ILocalize::AddFile() failed to load file "public/steambootstrapper_english.txt". +src/steamexe/updateui_xwin.cpp (1466) : BFileExists( m_FontFileRegular ) +src/steamexe/updateui_xwin.cpp (1466) : BFileExists( m_FontFileRegular ) +12/08 00:44:43 minidumps folder is set to /tmp/dumps +12/08 00:44:43 Init: Installing breakpad exception handler for appid(steam)/version(1.0)/tid(431) + +(hangs here) +``` + +Any help appreciated. \ No newline at end of file diff --git a/results/scraper/fex/4213 b/results/scraper/fex/4213 new file mode 100644 index 000000000..41b07b8a9 --- /dev/null +++ b/results/scraper/fex/4213 @@ -0,0 +1,6 @@ +{v,}ptest can be made more efficient with SVE +{v,}ptest is a bit of a weird family of instructions because it sets ZF and CF depending on if the full mask, or negated mask is all zeroes respectively. This is a bit of a faff with ASIMD since it doesn't match semantically, and AVX just adds even more instructions to it. + +With SVE they added the new `CMP<cc>` instructions which set both a predicate register and the NZCV flags. This can reduce the number of instructions that {v,}ptest requires by quite a bit. + +Likely worth implementing. \ No newline at end of file diff --git a/results/scraper/fex/4214 b/results/scraper/fex/4214 new file mode 100644 index 000000000..e3b4eb157 --- /dev/null +++ b/results/scraper/fex/4214 @@ -0,0 +1,39 @@ +Factorio: FPS drops massively when zooming out +**What Game** +Factorio `2.0.23 (build 80769 expansion, linux64)` (Space Age mods disabled) +https://store.steampowered.com/app/427520/Factorio/ + +**Describe the bug** +Massive FPS drop when zooming out. + +**To Reproduce** +Steps to reproduce the behavior: +1. Create a new singleplayer Freeplay game (I used seed 1) +2. Start the game +3. Observe that the game is running at 60 FPS +4. Zoom out +5. Observe that it drops to 15 FPS + +Note that some menu animations also drop to quite low FPS, I assume it's the same issue. + +**Expected behavior** +The game runs smoothly. + +**Screenshots and Video** + + + +**System information:** + - OS: NixOS unstable + - CPU/SoC: Snapdragon X Elite (X1E80100) + - Video driver version: Mesa 24.2.6 + - RootFS used: none (I use bubblewrap instead) + - FEX version: 2412 (+ this patch: https://github.com/kuruczgy/nixos-aarch64-gaming/blob/6a8acdb69f2963a3f5f998f3a65c8520dfffa6b8/packages/fex-emu-shebang-absolute-path-fix.patch ) + - Thunks Enabled: No + +See this commit for the nix expressions for the bwrap based chroot: https://github.com/kuruczgy/nixos-aarch64-gaming/tree/6a8acdb69f2963a3f5f998f3a65c8520dfffa6b8 + +**Additional context** + - Is this an x86 or x86-64 game: x86-64 + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: Unknown \ No newline at end of file diff --git a/results/scraper/fex/4217 b/results/scraper/fex/4217 new file mode 100644 index 000000000..a5a07d716 --- /dev/null +++ b/results/scraper/fex/4217 @@ -0,0 +1,34 @@ +SOMA: Cannot open drawers or kitchen cabinets in the starting room +**What Game** +SOMA +https://store.steampowered.com/app/282140/SOMA/ + +**Describe the bug** +Cannot open drawers or kitchen cabinets in the starting room. + +**To Reproduce** +Steps to reproduce the behavior: +1. Start a new game. (Wait for a few minutes until the cutscenes are over and you wake up in the starting room.) +2. Put your crosshair over a drawer or a kitchen cabinet in the room, and try to drag it by holding down the left mouse button. +3. Observe that the hand symbol that should appear when hovering is missing, and the dragging does not work. + +**Expected behavior** +You can open drawers and kitchen cabinet doors. + +**Screenshots and Video** +This is how it's supposed to work: https://youtu.be/FD0h-s6NUeM?t=311 + +**System information:** + - OS: NixOS unstable + - CPU/SoC: Snapdragon X Elite (X1E80100) + - Video driver version: Mesa 25.0.0-devel (commit a2339542f5d71b1c60febff78fb5dbad7ceb9191) + - RootFS used: none (I use bubblewrap instead) + - FEX version: 2412 (+ this patch: https://github.com/kuruczgy/nixos-aarch64-gaming/blob/6a8acdb69f2963a3f5f998f3a65c8520dfffa6b8/packages/fex-emu-shebang-absolute-path-fix.patch ) + - Thunks Enabled: No + +See this commit for the nix expressions for the bwrap based chroot: https://github.com/kuruczgy/nixos-aarch64-gaming/tree/a747c19f80f64ce566f315ac5c93d1b9345c13d4 + +**Additional context** + - Is this an x86 or x86-64 game: Unknown + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: Unknown diff --git a/results/scraper/fex/4219 b/results/scraper/fex/4219 new file mode 100644 index 000000000..0e110e573 --- /dev/null +++ b/results/scraper/fex/4219 @@ -0,0 +1,2 @@ +Error Running Wine in Arch Linux ARM +With latest release, 2412, Arch linux ARM for the Raspberry Pi complains about not being able to find ntdll.so. It looks like it is trying to load it from /proc/../lib32. It did work in the previous release, 2410. Also, not sure if this is related, but even in the working version sound is very crackly in 32 bit applications making them pretty much unusable. \ No newline at end of file diff --git a/results/scraper/fex/423 b/results/scraper/fex/423 new file mode 100644 index 000000000..629cb6585 --- /dev/null +++ b/results/scraper/fex/423 @@ -0,0 +1,3 @@ +Need unit tests that check CVT ops with different round modes +Currently all of our conversion op unit tests are assuming truncate. +We need unit tests that test all the different round modes correctly. \ No newline at end of file diff --git a/results/scraper/fex/4233 b/results/scraper/fex/4233 new file mode 100644 index 000000000..5f557fecb --- /dev/null +++ b/results/scraper/fex/4233 @@ -0,0 +1,35 @@ +[Project Zomboid (Build 42)]: Crash on startup +**What Game** +Project Zomboid (Build 42) +https://store.steampowered.com/app/108600/Project_Zomboid/ + +**Describe the bug** +Crash on startup. + +**To Reproduce** +Steps to reproduce the behavior: +1. Start game +2. See crash + +**Expected behavior** +Game starts + +**Logs** +https://pastebin.com/1Z9ZFex2 + +**System information:** + - OS: Gentoo Asahi Linux + - CPU/SoC: Apple M1 Max (G13C C0) + - Video driver version: `media-libs/mesa-25.0.0_pre20241204-r2` + - RootFS used: `app-emulation/fex-rootfs-gentoo-20241116` / `app-emulation/fex-rootfs-mesa-asahi-20241205` + - FEX version: `FEX-2412-17-gbdae4f6` + - Thunks Enabled: Yes + +**Additional context** + - Is this an x86 or x86-64 game: `x86-64` + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: No + - If Yes, What is your Vulkan driver: + +Add any other context about the problem here. +- might be related to https://github.com/FEX-Emu/FEX/issues/2142 \ No newline at end of file diff --git a/results/scraper/fex/4235 b/results/scraper/fex/4235 new file mode 100644 index 000000000..c60e7e039 --- /dev/null +++ b/results/scraper/fex/4235 @@ -0,0 +1,35 @@ +[Oxygen not Included]: Crash on map load +**What Game** +Oxygen not Included (Vanilla and Spaced Out! DLC) +https://store.steampowered.com/app/457140/Oxygen_Not_Included/ + +**Describe the bug** +After choosing dupes and hitting embark, the game crashes on map load. + +**To Reproduce** +1. Go to new game +2. Choose dupes +3. Click on 'Embark' +5. See error + +**Expected behavior** +Load the map + and allow playing the game +**Logs** +Vanilla: https://pastebin.com/74SSdf4C +Spaced out: https://pastebin.com/0eLCVYvt + +**System information:** + - OS: Gentoo Asahi Linux + - CPU/SoC: Apple M1 Max (G13C C0) + - Video driver version: `media-libs/mesa-25.0.0_pre20241204-r2` + - RootFS used: `app-emulation/fex-rootfs-gentoo-20241116` / `app-emulation/fex-rootfs-mesa-asahi-20241205` + - FEX version: `FEX-2412-17-gbdae4f6` + - Thunks Enabled: Yes + +**Additional context** + - Is this an x86 or x86-64 game: `x86-64` + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: Yes + - If Yes, What is your Vulkan driver: `Honeykrisp` + diff --git a/results/scraper/fex/4236 b/results/scraper/fex/4236 new file mode 100644 index 000000000..5529f8482 --- /dev/null +++ b/results/scraper/fex/4236 @@ -0,0 +1,32 @@ +HW Accel issue on rk3588 +Hello, I've recently switched from box64 to fex since i can't get steam/games working there. +When running steam i get the following harmless errors: (Steam runs fine but software rendered) +``` +MESA: error: failed to mmap the LATEST_FLUSH_ID register (err=22) +glx: failed to create dri3 screen +failed to load driver: rockchip +MESA: error: failed to mmap the LATEST_FLUSH_ID register (err=22) +glx: failed to create dri3 screen +failed to load driver: rockchip +ATTENTION: default value of option mesa_glthread overridden by environment. +MESA: error: failed to mmap the LATEST_FLUSH_ID register (err=22) +glx: failed to create dri3 screen +failed to load driver: rockchip +MESA: error: failed to mmap the LATEST_FLUSH_ID register (err=22) +glx: failed to create dri3 screen +failed to load driver: rockchip +ATTENTION: default value of option mesa_glthread overridden by environment. +MESA: error: failed to mmap the LATEST_FLUSH_ID register (err=22) +glx: failed to create dri3 screen +failed to load driver: rockchip +MESA: error: failed to mmap the LATEST_FLUSH_ID register (err=22) +glx: failed to create dri3 screen +failed to load driver: rockchip +``` +I've confirmed that /lib/dri/rockchip_dir.so exists in both the aarch64 root and x86_64 root +I've also checked using `glxinfo -B` and confirmed that hw accel is working +Even tried running a game, All works fine. + +Any ideas? + +Edit: I'm running linux 6.13.0-rc3 (Panthor GPU driver) with fex 2410-1 on armtix linux on an Orange Pi 5 Plus \ No newline at end of file diff --git a/results/scraper/fex/4238 b/results/scraper/fex/4238 new file mode 100644 index 000000000..51b00487d --- /dev/null +++ b/results/scraper/fex/4238 @@ -0,0 +1,43 @@ +[Left 4 Dead 2 Dedicated Server/SRCDS]: [Server crashes when game starting/player joins] +**What Game** +Left 4 Dead 2 Dedicated Server/SRCDS +Server: [https://developer.valvesoftware.com/wiki/SteamCMD](https://developer.valvesoftware.com/wiki/SteamCMD) +./steamcmd.sh +@sSteamCmdForcePlatformType linux +force_install_dir /home/ubuntu/l4d2server +login anonymous +app_update 222860 validate +quit +Game: https://store.steampowered.com/app/550/Left_4_Dead_2/ + +**Describe the bug** +Server crashes when game starting/player joins with the following message: +``` +src/clientcommon/webui_job_dispatcher.cpp (88) : Assertion Failed: WebUI method 'SteamEngine.UpdateTextFilterDictionary#1' has already been registered. Skipping duplicate registration +src/clientcommon/webui_job_dispatcher.cpp (88) : Assertion Failed: WebUI method 'SteamEngine.UpdateTextFilterDictionary#1' has already been registered. Skipping duplicate registration +12/29 18:58:22 Init: Installing breakpad exception handler for appid(srcds_linux)/version(1.0)/tid(164390) + +``` + +**To Reproduce** +Steps to reproduce the behavior: +1. install server using steamCMD as shown above and move to path inside chroot +2. chroot into instance by running/home/ubuntu/.fex-emu/RootFS/Ubuntu_22_04/break_chroot.sh +3. run server by running srcds_run +4. Join server using game client +5. See error from server console + +**Expected behavior** +No crashes + +**Screenshots and Video** + + +**System information:** + - OS: Ubuntu 22.04 + - CPU/SoC: Server Neoverse-N1 aarch64 + - RootFS used: [eg: Ubuntu 22.04 Official Rootfs] + - FEX version: FEX-2412 + - Thunks Enabled: No + +**Additional context** + - Is this an x86 or x86-64 game: [x86/x86-64/Both] + x86 + +Add any other context about the problem here. +Sorry, really new to FEX. Need help resolving this issue. Again this is not an issue with running the game but the Linux dedicated server component of it \ No newline at end of file diff --git a/results/scraper/fex/4247 b/results/scraper/fex/4247 new file mode 100644 index 000000000..e00b377e8 --- /dev/null +++ b/results/scraper/fex/4247 @@ -0,0 +1,2 @@ +cefsimple broken in latest FEX +Since #4195, cefsimple crashes during startup with the default FEX configuration. diff --git a/results/scraper/fex/4252 b/results/scraper/fex/4252 new file mode 100644 index 000000000..c0b1e598c --- /dev/null +++ b/results/scraper/fex/4252 @@ -0,0 +1,79 @@ +Crysis 2 Maximum edition: Audio thread completely saturated with x87, breaks audio +The first level of the game completely saturates its audio thread, resulting in it dropping samples. Even in reduced precision mode. Pretty much all the CPU time is spent in its fmodex.dll. and most of the blocks are just a ton of x87. + +``` + 19.30% [JIT] tid 494822 [.] JIT_0x2e7a85c_0x413e867fc + 11.39% [JIT] tid 494822 [.] JIT_0x2ea4521_0x413e642a4 + 10.69% [JIT] tid 494822 [.] JIT_0x2ea46e9_0x413e6d978 + 7.19% [JIT] tid 494822 [.] JIT_0x2e8e7af_0x413e94d28 + 4.86% [JIT] tid 494822 [.] JIT_0x2ea3931_0x413e39858 + 4.58% [JIT] tid 494822 [.] JIT_0x2e8e6e1_0x413ea3658 + 3.84% [JIT] tid 494822 [.] JIT_0x2e8e761_0x413ea3ce8 + 2.84% [JIT] tid 494822 [.] JIT_0x2ea4085_0x413e5119c + 2.74% [JIT] tid 494822 [.] JIT_0x2e8eb0d_0x413e9a00c + 2.12% [JIT] tid 494822 [.] JIT_0x2e735d4_0x413e9e090 + 2.05% [JIT] tid 494822 [.] JIT_0x2e8e659_0x413ea3330 + 1.62% [JIT] tid 494822 [.] JIT_0x2e8e373_0x413ea1cf0 + 1.39% FEXInterpreter [.] 0x0000000000185480 + 0.99% [JIT] tid 494822 [.] JIT_0x2e8eb51_0x413e9a79c + 0.90% [JIT] tid 494822 [.] JIT_0x2e8eb04_0x413e99a64 + 0.83% [JIT] tid 494822 [.] JIT_0x2e8e4dd_0x413e90e94 + 0.78% [JIT] tid 494822 [.] JIT_0x2ea46cf_0x413e69d04 + 0.78% [JIT] tid 494822 [.] JIT_0x2e8e4df_0x413e905ec + 0.70% [JIT] tid 494822 [.] JIT_0x2ea44ed_0x413e605dc + ``` +fmodex.dll base address at 0x2e20000 in this capture. + +First block: +```asm +02e7a85c fld st0, dword [edx] +02e7a85e dec dword [ebp+0x10 {arg4}] +02e7a861 fld st0, dword [0x2efbf50] +02e7a867 add edx, 0x8 +02e7a86a fld st0, st0 +02e7a86c faddp st2, st0 +02e7a86e fld st0, dword [esi+0x1c0] +02e7a874 fmulp st2, st0 +02e7a876 fld st0, dword [esi+0x1c4] +02e7a87c fmul st0, dword [ebp+0x14 {arg5}] +02e7a87f faddp st2, st0 +02e7a881 fxch st0, st1 +02e7a883 fstp dword [ebp+0xc {arg3}], st0 +02e7a886 fld st0, dword [edx-0x4] +02e7a889 fld st0, st1 +02e7a88b faddp st1, st0 +02e7a88d fmul st0, dword [esi+0x1c0] +02e7a893 fld st0, dword [esi+0x1c4] +02e7a899 fmul st0, dword [ebp-0x10 {var_14_1}] +02e7a89c faddp st1, st0 +02e7a89e fstp dword [ebp+0x8 {arg2}], st0 +02e7a8a1 fld st0, dword [ebp+0xc {arg3}] +02e7a8a4 fstp dword [ebp+0x14 {arg5}], st0 +02e7a8a7 fld st0, dword [ebp+0x8 {arg2}] +02e7a8aa fstp dword [ebp-0x10 {var_14_1}], st0 +02e7a8ad fld st0, dword [esi+0x1c0] +02e7a8b3 fmul st0, dword [ebp+0xc {arg3}] +02e7a8b6 fld st0, dword [esi+0x1c4] +02e7a8bc fmul st0, dword [ebp-0x14 {var_18_1}] +02e7a8bf faddp st1, st0 +02e7a8c1 fstp dword [ebp+0xc {arg3}], st0 +02e7a8c4 fld st0, dword [esi+0x1c0] +02e7a8ca fmul st0, dword [ebp+0x8 {arg2}] +02e7a8cd fld st0, dword [esi+0x1c4] +02e7a8d3 fmul st0, dword [ebp-0xc {var_10_1}] +02e7a8d6 faddp st1, st0 +02e7a8d8 fstp dword [ebp+0x8 {arg2}], st0 +02e7a8db fld st0, dword [ebp+0xc {arg3}] +02e7a8de fstp dword [ebp-0x14 {var_18_1}], st0 +02e7a8e1 fld st0, dword [ebp+0x8 {arg2}] +02e7a8e4 fstp dword [ebp-0xc {var_10_1}], st0 +02e7a8e7 fld st0, dword [ebp+0xc {arg3}] +02e7a8ea fstp dword [eax], st0 +02e7a8ec add eax, 0x8 +02e7a8ef cmp dword [ebp+0x10 {arg4}], 0x0 +02e7a8f3 fld st0, dword [ebp+0x8 {arg2}] +02e7a8f6 fstp dword [eax-0x4], st0 +02e7a8f9 fchs +02e7a8fb fstp dword [data_2efbf50], st0 +02e7a901 jne 0x2e7a85c +``` \ No newline at end of file diff --git a/results/scraper/fex/4255 b/results/scraper/fex/4255 new file mode 100644 index 000000000..46cd5406f --- /dev/null +++ b/results/scraper/fex/4255 @@ -0,0 +1,2 @@ +Adjust and parity flag extension +I've found [this article](https://bytecellar.com/2022/11/16/a-secret-apple-silicon-extension-to-accommodate-an-intel-8080-artifact/), about some undocumented extension in apple silicon cpus, designed to eliminate the need for parity and adjust flag calculations in software, and this project seems to be the only time and place in the universe where this might be useful. \ No newline at end of file diff --git a/results/scraper/fex/4261 b/results/scraper/fex/4261 new file mode 100644 index 000000000..67e6e6b57 --- /dev/null +++ b/results/scraper/fex/4261 @@ -0,0 +1,26 @@ +Wine unable to load kernel32.dll – Asahi Linux +Hi there, + +First of all thank you so much for your great work! I very much appreciate running x86_64 applications on my Asahi Linux system. I am on the Fedora Remix `6.12.4-400.asahi.fc41.aarch64+16k` on my Apple MacBook Pro (13-inch, M1, 2020). + +But for now I was unable to start wine. When do the following commands (after deleting the `.wine` folder): + +```bash +muvm -ti -- zsh +FEXBash +wineboot --init +``` + +I get the following output: + +```output +wine: created the configuration directory '/home/faressc/.wine' +002c:err:seh:install_bpf prctl(PR_SET_SECCOMP, ...): Invalid argument. +wine: could not load kernel32.dll, status c0000135 +0024:err:seh:install_bpf prctl(PR_SET_SECCOMP, ...): Invalid argument. +wine: could not load kernel32.dll, status c0000135 +``` + +Can you reproduce this error? + +Best wishes! \ No newline at end of file diff --git a/results/scraper/fex/4264 b/results/scraper/fex/4264 new file mode 100644 index 000000000..54ca59f79 --- /dev/null +++ b/results/scraper/fex/4264 @@ -0,0 +1,10 @@ +Cached predicate register being clobbered by softfp lib call +Unfortunately, the code to cache predicate registers for SVE x87 ldst optimization and the precision tests that do a bunch of: + +``` +load +op +store/pop +``` + +were developed at a similar time and landed more of less at a similar time. We might not have SVE hw in CI and I didn't test this until now. The culprit commit is 72a40636515aaa8986f500ce7f4c5cb546d6127f . What's happening is that in this specific case we are caching p2, calling softfp fcos impl which clobbers p2 and its use in fstp causes the bug - i.e. the test to fail. \ No newline at end of file diff --git a/results/scraper/fex/4267 b/results/scraper/fex/4267 new file mode 100644 index 000000000..8f4052f1c --- /dev/null +++ b/results/scraper/fex/4267 @@ -0,0 +1,14 @@ +Don't depend on any binary blobs +Currently the tests depend a bunch of prebuilt binaries through submodules, e.g. `External/fex-gcc-target-tests-bins` and some others. + +Binary blobs are bad from an auditability perspective. One could say that "those are just for tests so they don't count", but I am not aware of any distro packaging system that lets one (easily) selectively clone submodules, so in practice they are all present during builds. + +Building the test binaries from source would be an obvious idea, but e.g. pulling in the whole gcc repo is probably even less desirable than the current solution, so I see why it's not done. + +Ideas for alternatives: +- Instead of using submodules, manually `git clone --depth 1` the bin repos in the CI. +- Maybe there is some way to configure `.gitmodules` to not clone these submodules by default with `git clone --recursive`? E.g. not sure if `submodule.<name>.fetchRecurseSubmodules` does that. + +In either case, it should be documented which submodules are needed for building FEX and which ones only for the tests (and which tests), currently it's a bit of a guessing game. + +Also honorable mention to `Source/Windows/wine_builtin.bin`, but that's small enough to be audited by hand with a hex editor, so it's not a priority. (It's just text with some null bytes afterwards.) \ No newline at end of file diff --git a/results/scraper/fex/4279 b/results/scraper/fex/4279 new file mode 100644 index 000000000..91c24a91b --- /dev/null +++ b/results/scraper/fex/4279 @@ -0,0 +1,3 @@ +PKGBUILD deletion? +Hey um.. What happened with the fex PKGBUILD on the AUR? +Did the AUR people take it down because the package is only available for aarch64 and not ArchLinux (x86_64)? \ No newline at end of file diff --git a/results/scraper/fex/4280 b/results/scraper/fex/4280 new file mode 100644 index 000000000..29fde1fb2 --- /dev/null +++ b/results/scraper/fex/4280 @@ -0,0 +1,12 @@ +Some 3DNow tests are broken on Oryon +Specifically, the following: + +``` +Test_3DNow/86.asm +Test_3DNow/87.asm +Test_3DNow/96.asm +Test_3DNow/97.asm +``` + +According to @Sonicadvance1: +> Yea, this test failure is expected on FEAT_RPRES supporting devices. We need to add some ability to our ASM tests to know how to they are safe to be off by 1-bit of precision. Or just run with `FEX_HOSTFEATURES=disableafp,disablerpres` \ No newline at end of file diff --git a/results/scraper/fex/4281 b/results/scraper/fex/4281 new file mode 100644 index 000000000..0b1bd985d --- /dev/null +++ b/results/scraper/fex/4281 @@ -0,0 +1,37 @@ +The logic to check unsquashfs might be wrong +I can see in the codebase that `--help` is used to check. + +however: + +``` +unsquashfs --help +unsquashfs: --help is an invalid option + +Run + "unsquashfs -help-option <regex>" to get help on all options +matching <regex> + +Or run + "unsquashfs -help-section <section-name>" to get help on these sections + SECTION NAME SECTION + extraction Filesystem extraction (filtering) + options: + information Filesystem information and listing + options: + xattrs Filesystem extended attribute + (xattrs) options: + runtime Unsquashfs runtime options: + help Help options: + misc Miscellaneous options: + environment Environment: + exit Exit status: + extra See also (extra information + elsewhere): + decompressors Decompressors available: + +Or run + "unsquashfs -help-all" to get help on all the sections +~ [1]$ +``` + +I compiled squashfs tools with commit f77b633f3a5bfb3e199286deed037b1c7f03ba91 ffom https://github.com/plougher/squashfs-tools.git \ No newline at end of file diff --git a/results/scraper/fex/4296 b/results/scraper/fex/4296 new file mode 100644 index 000000000..85d0dd84a --- /dev/null +++ b/results/scraper/fex/4296 @@ -0,0 +1,54 @@ +Changes to primary.json not easily explained +I have noticed that since about August 2024, some HW shows unexplained changes to Primary.json. I have been reverting those before pushing because I think the cause is probably a bug or corner case, but it might be worth spending some time looking into it. + +This is what I see as a diff after running instcountci: + +``` +diff --git a/unittests/InstructionCountCI/Primary.json b/unittests/InstructionCountCI/Primary.json +index 6d31a617d..4038bb2ad 100644 +--- a/unittests/InstructionCountCI/Primary.json ++++ b/unittests/InstructionCountCI/Primary.json +@@ -1996,10 +1996,10 @@ + "ExpectedInstructionCount": 4, + "Comment": "0x86", + "ExpectedArm64ASM": [ +- "mov x20, x7", +- "bfxil x20, x6, #0, #8", +- "bfxil x6, x7, #0, #8", +- "mov x7, x20" ++ "mov x20, x6", ++ "bfxil x20, x7, #0, #8", ++ "bfxil x7, x6, #0, #8", ++ "mov x6, x20" + ] + }, + "xchg [rax], cl": { +@@ -2014,10 +2014,10 @@ + "ExpectedInstructionCount": 4, + "Comment": "0x87", + "ExpectedArm64ASM": [ +- "mov x20, x7", +- "bfxil x20, x6, #0, #16", +- "bfxil x6, x7, #0, #16", +- "mov x7, x20" ++ "mov x20, x6", ++ "bfxil x20, x7, #0, #16", ++ "bfxil x7, x6, #0, #16", ++ "mov x6, x20" + ] + }, + "xchg [rax], cx": { +@@ -2032,9 +2032,9 @@ + "ExpectedInstructionCount": 3, + "Comment": "0x87", + "ExpectedArm64ASM": [ +- "mov w20, w6", +- "mov w6, w7", +- "mov x7, x20" ++ "mov w20, w7", ++ "mov w7, w6", ++ "mov x6, x20" + ] + }, + "xchg [rax], ecx": { +``` \ No newline at end of file diff --git a/results/scraper/fex/43 b/results/scraper/fex/43 new file mode 100644 index 000000000..0b71ec6f3 --- /dev/null +++ b/results/scraper/fex/43 @@ -0,0 +1,2 @@ +Guest backtrace support +Support guest backtrace to know where the guest ends up at when we crash \ No newline at end of file diff --git a/results/scraper/fex/4301 b/results/scraper/fex/4301 new file mode 100644 index 000000000..b55a1aba4 --- /dev/null +++ b/results/scraper/fex/4301 @@ -0,0 +1,46 @@ +Investigate whether dynamic linking triggers spurious allocations +EDIT (neobrain): The original observation stem from an invalid CI configuration. It's unconfirmed at this point whether dynamic linking incurs any spurious allocations. Original observation follows: + +<hr> + +#5476 uncovered this issue using the glibc fault CI test. A runner happened to have libxxhash-dev installed, which causes symbol lookup to happen dynamically, which causes glibc allocations. +``` +Program terminated with signal SIGILL, Illegal instruction. +#0 FEXCore::Assert::ForcedAssert () at /home/ryanh/FEX/FEXCore/Source/Utils/ForcedAssert.cpp:9 +9 asm volatile("hlt #1"); +(gdb) y +Undefined command: "y". Try "help". +(gdb) bt +#0 FEXCore::Assert::ForcedAssert () at /home/ryanh/FEX/FEXCore/Source/Utils/ForcedAssert.cpp:9 +#1 0x0000aaaac2ac23f0 in FEXCore::Allocator::EvaluateReturnAddress (Return=0xffffbb8c0ed4 <__GI__dl_exception_create_format+244>) at /home/ryanh/FEX/FEXCore/Source/Utils/AllocatorOverride.cpp:114 +#2 0x0000aaaac2ac20e4 in fault_malloc (size=56) at /home/ryanh/FEX/FEXCore/Source/Utils/AllocatorOverride.cpp:130 +#3 0x0000ffffbb8c0ed4 in malloc (size=56) at ../include/rtld-malloc.h:56 +#4 __GI__dl_exception_create_format (exception=exception@entry=0xffffeda66d68, objname=0xffffeda6c721 "./Bin/FEXLoader", fmt=fmt@entry=0xffffbb8df4d0 "undefined symbol: %s%s%s") at ./elf/dl-exception.c:157 +#5 0x0000ffffbb8c74a8 in _dl_lookup_symbol_x (undef_name=0xaaaac2508f06 "XXH3_64bits", undef_map=undef_map@entry=0xffffbb8fa370, ref=ref@entry=0xffffeda66dd8, symbol_scope=<optimized out>, version=0xffffbb8bb018, type_class=type_class@entry=1, + flags=1, skip_map=skip_map@entry=0x0) at ./elf/dl-lookup.c:877 +#6 0x0000ffffbb8cd080 in _dl_fixup (l=0xffffbb8fa370, reloc_arg=3504) at ./elf/dl-runtime.c:95 +#7 0x0000ffffbb8cf1ac in _dl_runtime_resolve () at ../sysdeps/aarch64/dl-trampoline.S:100 +#8 0x0000aaaac2794140 in FEXCore::IR::AOTIRCaptureCache::LoadAOTIRCacheEntry (this=0xffffbae70568, filename="/home/ryanh/.fex-emu/RootFS/Ubuntu_22_04/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2") + at /home/ryanh/FEX/FEXCore/Source/Interface/IR/AOTIR.cpp:384 +#9 0x0000aaaac2662414 in FEXCore::Context::ContextImpl::LoadAOTIRCacheEntry (this=0xffffbae70000, filename="/home/ryanh/.fex-emu/RootFS/Ubuntu_22_04/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2") + at /home/ryanh/FEX/FEXCore/Source/Interface/Core/Core.cpp:1054 +#10 0x0000aaaac28d6d64 in FEX::HLE::SyscallHandler::TrackMmap (this=0xffffbae70800, Thread=0x0, Base=140737352839168, Size=8192, Prot=1, Flags=2066, fd=6, Offset=0) + at /home/ryanh/FEX/Source/Tools/LinuxEmulation/LinuxSyscalls/SyscallsSMCTracking.cpp:214 +#11 0x0000aaaac2948e68 in FEX::HLE::x64::x64SyscallHandler::GuestMmap (this=0xffffbae70800, Thread=0x0, addr=0x7ffff7ec3000, length=8192, prot=1, flags=2066, fd=6, offset=0) + at /home/ryanh/FEX/Source/Tools/LinuxEmulation/LinuxSyscalls/x64/Memory.cpp:41 +#12 0x0000aaaac2645888 in ELFCodeLoader::MapFile (this=0xffffeda6afa0, file=..., Base=140737352839168, Header=..., prot=1, flags=2066, Handler=0xffffbae70800) at /home/ryanh/FEX/Source/Tools/FEXLoader/ELFCodeLoader.h:81 +#13 0x0000aaaac2644d24 in ELFCodeLoader::LoadElfFile (this=0xffffeda6afa0, Elf=..., BrkBase=0x0, Handler=0xffffbae70800, LoadHint=0) at /home/ryanh/FEX/Source/Tools/FEXLoader/ELFCodeLoader.h:147 +#14 0x0000aaaac26343a4 in ELFCodeLoader::MapMemory (this=0xffffeda6afa0, Handler=0xffffbae70800) at /home/ryanh/FEX/Source/Tools/FEXLoader/ELFCodeLoader.h:472 +#15 0x0000aaaac262e688 in main (argc=7, argv=0xffffeda6b798, envp=0xffffeda6b7d8) at /home/ryanh/FEX/Source/Tools/FEXLoader/FEXLoader.cpp:567 +(gdb) frame 8 +#8 0x0000aaaac2794140 in FEXCore::IR::AOTIRCaptureCache::LoadAOTIRCacheEntry (this=0xffffbae70568, filename="/home/ryanh/.fex-emu/RootFS/Ubuntu_22_04/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2") + at /home/ryanh/FEX/FEXCore/Source/Interface/IR/AOTIR.cpp:384 +384 auto filename_hash = XXH3_64bits(filename.c_str(), filename.size()); +(gdb) +``` + +We can not dynamically link xxhash at the very least. We should double check our other dependencies to ensure we don't hit dynamic linking. + +At the end of the day we should only dynamically link against PT_INTERP, libc, libgcc_s, libm, and libstdc++. + +Ideally we could also get rid of libstdc++ but I'm not sure if that's viable when doing dlopen against C++ libraries? Would need a bit more investigation for that one. \ No newline at end of file diff --git a/results/scraper/fex/4304 b/results/scraper/fex/4304 new file mode 100644 index 000000000..809d348f0 --- /dev/null +++ b/results/scraper/fex/4304 @@ -0,0 +1,21 @@ +Latest Steam stable update (Jan 2025) fails to start due to CEF crash loop +Steam fails to start up since last week's update due to a crash in CEF's network service, indicated by webhelper-linux.txt: +``` +[2025-01-27 16:23:23] terminate called after throwing an instance of 'std::out_of_range' +[2025-01-27 16:23:23] what(): basic_string::at: __n (which is 0) >= this->size() (which is 0) +[2025-01-27 16:23:23] [0127/162323.751259:ERROR:network_service_instance_impl.cc(600)] Network service crashed, restarting service. +[2025-01-27 16:23:23] [DEBUG] Hiding directory entry for RootFSFD +[2025-01-27 16:23:23] [DEBUG] Hiding directory entry for RootFSFD +[2025-01-27 16:23:23] terminate called after throwing an instance of 'std::out_of_range' +[2025-01-27 16:23:23] what(): basic_string::at: __n (which is 0) >= this->size() (which is 0) +[2025-01-27 16:23:23] [0127/162323.912938:ERROR:network_service_instance_impl.cc(600)] Network service crashed, restarting service. +[2025-01-27 16:23:23] [DEBUG] Hiding directory entry for RootFSFD +[2025-01-27 16:23:23] [DEBUG] Hiding directory entry for RootFSFD +[2025-01-27 16:23:23] terminate called after throwing an instance of 'std::out_of_range' +[2025-01-27 16:23:23] what(): basic_string::at: __n (which is 0) >= this->size() (which is 0) +[2025-01-27 16:23:24] [0127/162324.060614:ERROR:network_service_instance_impl.cc(600)] Network service crashed, restarting service. + +... +``` + +This has been reproduced on 3 different devices (macbook with Linux VM, X13s, T14s). Downgrading the Steam client to the 20241204072114 update reliably resolves the problem. diff --git a/results/scraper/fex/4312 b/results/scraper/fex/4312 new file mode 100644 index 000000000..8b7cd2a90 --- /dev/null +++ b/results/scraper/fex/4312 @@ -0,0 +1,7 @@ +FEXConfig input issues +When trying to input a string in one of the boxes, I type a letter, the textbox loses focus and there's a small "sleep", type another letter and so on. Each time I try to type something I get in the console: +``` +qrc:/qt-project.org/imports/QtQuick/Controls/Fusion/SpinBox.qml:30:18: QML QQuickTextInput: Binding loop detected for property "text" +``` + +This is with qt6 on Ubuntu 24.10 on the Lenovo T14s \ No newline at end of file diff --git a/results/scraper/fex/4319 b/results/scraper/fex/4319 new file mode 100644 index 000000000..ede6d16af --- /dev/null +++ b/results/scraper/fex/4319 @@ -0,0 +1,8 @@ +Reciprocal estimate not accurate enough +Currently on systems with rpres extension we generate `frecpe` for a `pfrcp`. The AMD manual mentions: + +> The maximum error is less than or equal to 1.5 * 2^–12 times the true reciprocal. + +Unfortunately for, for example 1.0, the result of `frecpe` is 0.998047. The result should be within `(1.00037 | 0.999634)` to be within the required accuracy. + +Should check other functions as well. \ No newline at end of file diff --git a/results/scraper/fex/4320 b/results/scraper/fex/4320 new file mode 100644 index 000000000..254743e66 --- /dev/null +++ b/results/scraper/fex/4320 @@ -0,0 +1,2 @@ +Linux: Protect the end of the alt-stack +On alt-stack overflow this can/will corrupt our pointers. We should protect the end of this. \ No newline at end of file diff --git a/results/scraper/fex/4321 b/results/scraper/fex/4321 new file mode 100644 index 000000000..de26254a4 --- /dev/null +++ b/results/scraper/fex/4321 @@ -0,0 +1,9 @@ +Issue on termux inside ubuntu proot container +root@localhost:~/cb/DEBS# FEXBash collaboraoffice-base_24.04.12-20250131_amd64.deb +fuse: failed to open /dev/fuse: Permission denied +/tmp/.FEXMount9562-v1cPzJ/bin/sh: command not found +root@localhost:~/cb/DEBS# fusermount failed to execute. You may have an mount living at '/tmp/.FEXMount9562-v1cPzJ' to clean up now +Try `fusermount -u -q /tmp/.FEXMount9562-v1cPzJ` + + +I was trying to launch collabora office \ No newline at end of file diff --git a/results/scraper/fex/4323 b/results/scraper/fex/4323 new file mode 100644 index 000000000..ef12ea3a9 --- /dev/null +++ b/results/scraper/fex/4323 @@ -0,0 +1,19 @@ +No RootFS download available for Ubuntu 24.10 +I just came here from [this video](https://www.youtube.com/watch?v=_Uu99AvB6PY) from UbuntuConf 2024 and wanted to try FEX out. However, I'm running Ubuntu 24.10 on a Lenovo Yoga Slim 7x with arm64. When I ran the installer script, I got a list of RootFS alternatives, but none of them match my Ubuntu version. Should I use the closest one (24.04) or do something else in order to be able to proceed? + +Debugging info: + +``` +fex-emu-armv8.4 (2501~o) ... +fex-emu-binfmt32 (2501~o) ... +fex-emu-binfmt64 (2501~o) ... + +$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 24.10 +Release: 24.10 +Codename: oracular +$ uname -a +Linux user-Yoga-Slim-7-14Q8X9 6.12.0-28-qcom-x1e #28-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 24 03:56:34 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux +``` \ No newline at end of file diff --git a/results/scraper/fex/4329 b/results/scraper/fex/4329 new file mode 100644 index 000000000..45637adbb --- /dev/null +++ b/results/scraper/fex/4329 @@ -0,0 +1,59 @@ +Failure to setup client after installation +**Describe the bug** +After installing Fex on my arm64 laptop (Lenovo Yoga Slim7x) running Ubuntu Concept 24.10, choosing the Ubuntu 24.04 SquashFS, using it as-is and setting it as the default, the "trying basic program run" step fails with the following error message: + +> FEX is now installed. Trying basic program run +> [ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 111 +> [ERROR] Couldn't connect to FEXServer socket /run/user/1000/1000.FEXServer.Socket 111 +> [ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 111 +> [ERROR] Couldn't connect to FEXServer socket /run/user/1000/1000.FEXServer.Socket 111 +> [ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 111 +> [ERROR] Couldn't connect to FEXServer socket /run/user/1000/1000.FEXServer.Socket 111 +> [ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 111 +> [ERROR] Couldn't connect to FEXServer socket /run/user/1000/1000.FEXServer.Socket 111 +> [ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket 111 +> [ERROR] Couldn't connect to FEXServer socket /run/user/1000/1000.FEXServer.Socket 111 +> [ERROR] Couldn't connect to FEXServer socket 1000.FEXServer.Socket after launching the process +> [ERROR] FEXServerClient: Failure to setup client +> FEXInterpreter failed to run. Not continuing + + +**To Reproduce** +Steps to reproduce the behavior: +1. Have a Lenovo Yoga Slim7x laptop running Ubuntu Concept 24.10. +2. Run the installer with `curl --silent https://raw.githubusercontent.com/FEX-Emu/FEX/main/Scripts/InstallFEX.py --output /tmp/InstallFEX.py && python3 /tmp/InstallFEX.py && rm /tmp/InstallFEX.py` +3. Select `Ubuntu 24.04 (SquashFS)` in the RootFS selection step. +4. Use the squashFS file as-is (option 2). +5. Set Ubuntu_24_04.sqsh as the default RootFS. +6. Installer crashes with above error. + +**Expected behavior** +Expected basic program run to succeed. + +**Screenshots and Video** +N/A. + +**System information:** + - OS: Ubuntu Concept 24.10 + - CPU/SoC: Snapdragon X1 Elite + - Video driver version: N/A (yes, really! no Adreno X1-85 gfx driver released for linux yet) + - RootFS used: Ubuntu 24.04 (SquashFS) + - FEX version: FEX-2501 + - Thunks Enabled: Don't know. + +**Additional context** + - Is this an x86 or x86-64 game: N/A + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: No + +Add any other context about the problem here. + +> $ lsb_release -a +> No LSB modules are available. +> Distributor ID: Ubuntu +> Description: Ubuntu 24.10 +> Release: 24.10 +> Codename: oracular + +> $ uname -a +> Linux ola-Yoga-Slim-7-14Q8X9 6.12.0-28-qcom-x1e #28-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 24 03:56:34 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux \ No newline at end of file diff --git a/results/scraper/fex/4339 b/results/scraper/fex/4339 new file mode 100644 index 000000000..9e01133a0 --- /dev/null +++ b/results/scraper/fex/4339 @@ -0,0 +1,5 @@ +Psychonauts has flickering geometry +Not sure if this is a FEX regression or a Mesa regression. +On the title screen the "save door" flickers, when in-game all the geometry of the characters are flickering. + +Tested with Native Linux version of the game on Snapdragon X1E. \ No newline at end of file diff --git a/results/scraper/fex/4348 b/results/scraper/fex/4348 new file mode 100644 index 000000000..965bc7332 --- /dev/null +++ b/results/scraper/fex/4348 @@ -0,0 +1,4 @@ +Investigate what's missing with EasyAntiCheat +Not sure what's missing here, it's a known unknown. Collate a list of games that use EAC and have the Proton support enabled, then try to find a game that is relatively small for testing. + +Apparently Fall Guys was only like 8GB, but it recently updated and removed support for Proton. \ No newline at end of file diff --git a/results/scraper/fex/4369 b/results/scraper/fex/4369 new file mode 100644 index 000000000..3ba96667f --- /dev/null +++ b/results/scraper/fex/4369 @@ -0,0 +1,9 @@ +FEX does not comply with the "XDG Base Directory Specification" +According to the [spec](https://specifications.freedesktop.org/basedir-spec/latest/#variables): + +> $XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used. +> $XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used. + +But if both of these are unset, FEX creates its config directory at `$HOME/.fex-emu`, instead of under `$HOME/.config`. + +Also it seems that if `$XDG_CONFIG_HOME` is set then `$XDG_CONFIG_HOME/.fex-emu` is used. I think `$XDG_CONFIG_HOME/fex-emu` should be used instead, since this is the convention that pretty much every other application follows (not creating hidden directories under `$XDG_CONFIG_HOME`). \ No newline at end of file diff --git a/results/scraper/fex/4372 b/results/scraper/fex/4372 new file mode 100644 index 000000000..513981c23 --- /dev/null +++ b/results/scraper/fex/4372 @@ -0,0 +1,39 @@ +MiSide: Clothes can not render properly +**What Game** +MiSide + +https://store.steampowered.com/app/2527500/MiSide/ + + +**Describe the bug** +The default clothes cannot be displayed properly. +On Box64 we can change BOX64_DYNAREC_FASTNAN to false to solve this issue but we can't find any NaN related config on FEX. + + +**To Reproduce** +Steps to reproduce the behavior: +1. Start Game +2. Click 'Clothes' option and select 'Default' +3. See error + +**Expected behavior** +Clothes can render normally + +**Screenshots and Video** + + + +**System information:** + - OS: Android + - CPU/SoC: Snapdragon SM8550 + - Video driver version: Nightly build ARM64EC + - RootFS used: No + - FEX version: Build with 6651f9e94ba976983c63e02d4a871ddc019458d3 + - Thunks Enabled: NA, ARM64EC build + +**Additional context** + - Is this an x86 or x86-64 game: x86-64 + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: Yes - DXVK + - If Yes, What is your Vulkan driver: Mesa Turnip + diff --git a/results/scraper/fex/4375 b/results/scraper/fex/4375 new file mode 100644 index 000000000..819948c9a --- /dev/null +++ b/results/scraper/fex/4375 @@ -0,0 +1,24 @@ +InstallFEX error with fex-emu-binfmt32/64 +As many people here I am trying to use FEX on an OCI Ampere (so arm64), trying to build a Dockerfile on debian:bullseye-slim. I keep getting this error and don't find much documentation online on systemd-binfmt. + +``` +systemd-binfmt: unrecognized service +dpkg: error processing package fex-emu-binfmt32 (--configure): + installed fex-emu-binfmt32 package post-installation script subprocess returned error exit status 1 +[...] +Errors were encountered while processing: + fex-emu-binfmt32 + fex-emu-binfmt64 +``` + +Here is the Dockerfile sample if it can help : + +```dockerfile +FROM debian:bullseye-slim + +RUN apt update && apt install -y curl python3 sudo expect-dev software-properties-common + +RUN curl --silent https://raw.githubusercontent.com/FEX-Emu/FEX/main/Scripts/InstallFEX.py --output /tmp/InstallFEX.py + +RUN python3 /tmp/InstallFEX.py +``` \ No newline at end of file diff --git a/results/scraper/fex/4379 b/results/scraper/fex/4379 new file mode 100644 index 000000000..b2a1b44ae --- /dev/null +++ b/results/scraper/fex/4379 @@ -0,0 +1,2 @@ +How to override hostfeatures by Config.json ? +I can override hostfeature by passing arguments to FEXLoader easily. But how can I do it by modify Config.json? \ No newline at end of file diff --git a/results/scraper/fex/4380 b/results/scraper/fex/4380 new file mode 100644 index 000000000..2e742dd18 --- /dev/null +++ b/results/scraper/fex/4380 @@ -0,0 +1,4 @@ +would this be posible to work on debian 12 +debian 12 is the default linux container distro of chromeos and i would be great to get FEX to work on that distro for it to execute x86 linux apps on arm based chromebooks like mine + +thanks :D \ No newline at end of file diff --git a/results/scraper/fex/4393 b/results/scraper/fex/4393 new file mode 100644 index 000000000..55f6aeebc --- /dev/null +++ b/results/scraper/fex/4393 @@ -0,0 +1,32 @@ +Deus Ex: Human Revolution: 2d53867668af x87 optimisations causes early CTD on Apple M2/M2 Pro/M2 Max +**What Game** +Deus Ex: Human Revolution +I am testing with the retail copy which is no longer available on Steam, but Director's cut should be the same and can be found at https://store.steampowered.com/agecheck/app/238010/ + +**Describe the bug** +The game's menu system is heavy on x87. 2d53867668af introduces optimisations which cause the game to crash to desktop before the copyright information (the first frame after loading the game) is shown. This occurs both with and without reduced precision enabled. + +**To Reproduce** +Steps to reproduce the behavior: +1. Open Deus Ex: Human Revolution +2. Game loads its window/fullscreen surface then immediately crashes to desktop + +**Expected behavior** +The game should not crash to desktop + +**System information:** + - OS: Gentoo Linux + - CPU/SoC: Apple M2 Max + - Video driver version: Asahi Mesa 20241204 + - RootFS used: Gentoo RootFS with Asahi Mesa overlayed + - FEX version: FEX-2502 + - Thunks Enabled: No + +**Additional context** + - Is this an x86 or x86-64 game: x86 + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: Yes via DXVK + - If Yes, What is your Vulkan driver: Honeykrisp + +Add any other context about the problem here. +I cannot reproduce this on M1 series hardware interestingly enough... \ No newline at end of file diff --git a/results/scraper/fex/4398 b/results/scraper/fex/4398 new file mode 100644 index 000000000..003aae0b2 --- /dev/null +++ b/results/scraper/fex/4398 @@ -0,0 +1,32 @@ +Psychonauts: Low precision lighting problem +**What Game** +[Psychonauts](https://store.steampowered.com/app/3830/Psychonauts/) + +**Describe the bug** +Game rendering seems to have broken lighting in some way. Looks like per-vertex lighting only or something. + +**To Reproduce** +Steps to reproduce the behavior: +1. Start the game +2. Zoom in on the main character's face. + +**Expected behavior** +The game to look correct + +**Screenshots and Video** + + + +**System information:** + - OS: Debian 12 + - CPU/SoC: Radxa Orion O6 with Radeon Pro W7500 + - Video driver version: 4.6 (Compatibility Profile) Mesa 25.0.0 - kisak-mesa PPA + - RootFS used: Ubuntu 24.04 rootfs + - FEX version: FEX-2503-30-g10d34c9 + - Thunks Enabled:No + +**Additional context** + - Is this an x86 or x86-64 game: x86 + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Yes + - Is this a Vulkan game: No, OpenGL + - If Yes, What is your Vulkan driver: \ No newline at end of file diff --git a/results/scraper/fex/4407 b/results/scraper/fex/4407 new file mode 100644 index 000000000..36fe490f5 --- /dev/null +++ b/results/scraper/fex/4407 @@ -0,0 +1,19 @@ +ThunkLibs fail to build with LLVM 20 +We've started hitting this in Fedora Rawhide and Fedora Linux 42, which both use LLVM 20, and it doesn't repro in Fedora Linux 41 which uses LLVM 19. + +``` +/builddir/build/BUILD/fex-emu-2502-build/FEX-FEX-2502/ThunkLibs/Generator/gen.cpp:810:12: error: no matching member function for call to 'createDiagnostics' + 810 | Compiler.createDiagnostics(DiagConsumer, false); + | ~~~~~~~~~^~~~~~~~~~~~~~~~~ +/usr/lib64/llvm20/include/clang/Frontend/CompilerInstance.h:687:8: note: candidate function not viable: no known conversion from 'clang::DiagnosticConsumer *' to 'llvm::vfs::FileSystem &' for 1st argument 687 | void createDiagnostics(llvm::vfs::FileSystem &VFS, + | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~ +/usr/lib64/llvm20/include/clang/Frontend/CompilerInstance.h:710:3: note: candidate function not viable: no known conversion from 'clang::DiagnosticConsumer *' to 'llvm::vfs::FileSystem &' for 1st argument 710 | createDiagnostics(llvm::vfs::FileSystem &VFS, DiagnosticOptions *Opts, + | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~ +1 error generated. +``` + +This looks possibly related to https://github.com/llvm/llvm-project/commit/df9a14d7bbf1180e4f1474254c9d7ed6bcb4ce55 or something around it (thanks to s0ullight for digging it up). + +I've repro'd this with both 2502 and 2503. + +Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2351394 \ No newline at end of file diff --git a/results/scraper/fex/443 b/results/scraper/fex/443 new file mode 100644 index 000000000..4fa6192bf --- /dev/null +++ b/results/scraper/fex/443 @@ -0,0 +1,2 @@ +PSAD could probably be implemented with NEON SABDL +Haven't looked too closely, but would speed that up a bit if it works. \ No newline at end of file diff --git a/results/scraper/fex/4431 b/results/scraper/fex/4431 new file mode 100644 index 000000000..23a5aab70 --- /dev/null +++ b/results/scraper/fex/4431 @@ -0,0 +1,176 @@ +Left 4 Dead 2 Dedicated Server: Segmentation fault with Sourcemod installed +**What Game** +Left 4 Dead 2 Dedicated Server, freely available + +**Describe the bug** +Left 4 Dead 2 Dedicated Server segfaults if Sourcemod is installed. I noticed this issue [https://github.com/FEX-Emu/FEX/issues/4238](https://github.com/FEX-Emu/FEX/issues/4238) and ostensibly my setup is the same hardware just with a newer FEX/Ubuntu version. `-noassert` does not help in my case (still segfaults). Also really new to FEX! + +The game server works fine without Sourcemod installed. Metamod is required to activate Sourcemod, but Metamod works fine without Sourcemod installed. Workshop mods work fine too. The L4D2 server with Metamod/Sourcemod does not segfault on a x64 machine with the needed x86 stuff added. + +**To Reproduce** +Steps to reproduce the behavior: +``` +sudo useradd -m -u 6900 l4d2 +yes '1' | sudo su - l4d2 bash -c "FEXRootFSFetcher" + +sudo su l4d2 -c "wget -O /home/l4d2/steamcmd.tar.gz https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz" +sudo su l4d2 -c "mkdir -p /home/l4d2/steamcmd" +sudo su l4d2 -c "tar -xzf /home/l4d2/steamcmd.tar.gz -C /home/l4d2/steamcmd" +sudo rm "/home/l4d2/steamcmd.tar.gz" + +sudo su l4d2 -c "/home/l4d2/steamcmd/steamcmd.sh +force_install_dir /home/l4d2/l4d2_server +@sSteamCmdForcePlatformType windows +login anonymous +app_update 222860" +``` + +when it has installed the Windows version, in another terminal type `sudo rm -r /home/l4d2/l4d2_server/*` and then back in the `Steam >` terminal type `@sSteamCmdForcePlatformType linux` then `app_update 222860 validate` then `quit`. This switcheroo is required because Valve blocked anonymous installation of the Linux version of L4D2 idk why but it works if you install the windows version, wipe it, then linux on top (you may not need to wipe it) + +``` +# fixes possibly spurious error +sudo su l4d2 -c "mkdir -p /home/l4d2/.steam/sdk32/" +sudo su l4d2 -c "ln -s '/home/l4d2/steamcmd/linux32/steamclient.so' '/home/l4d2/.steam/sdk32/steamclient.so'" + +link2paste='https://mms.alliedmods.net/mmsdrop/1.12/mmsource-1.12.0-git1217-linux.tar.gz' +file2get=$(basename "$link2paste") +dir2get=$(basename $file2get .tar.gz) +sudo su l4d2 -c "wget -O /tmp/$file2get \"$link2paste\"" +sudo su l4d2 -c "mkdir -p /tmp/$dir2get" +sudo su l4d2 -c "tar -xzf /tmp/$file2get -C /tmp/$dir2get" +sudo su l4d2 -c "cp -a /tmp/$dir2get/. /home/l4d2/l4d2_server/left4dead2/" +sudo rm "/tmp/$file2get" +sudo rm -r "/tmp/$dir2get" + +link2paste='https://sm.alliedmods.net/smdrop/1.12/sourcemod-1.12.0-git7195-linux.tar.gz' +file2get=$(basename "$link2paste") +dir2get=$(basename $file2get .tar.gz) +sudo su l4d2 -c "wget -O /tmp/$file2get \"$link2paste\"" +sudo su l4d2 -c "mkdir -p /tmp/$dir2get" +sudo su l4d2 -c "tar -xzf /tmp/$file2get -C /tmp/$dir2get" +sudo su l4d2 -c "cp -a /tmp/$dir2get/. /home/l4d2/l4d2_server/left4dead2/" +sudo rm "/tmp/$file2get" +sudo rm -r "/tmp/$dir2get" + +sudo sh -c "cat <<EOF > /etc/systemd/system/l4d2.service +[Unit] +Description=L4D2 Dedicated Server +Wants=network-online.target +After=network-online.target + +[Service] +Environment=SteamAppId=222860 +Environment=LD_LIBRARY_PATH=/home/l4d2/l4d2_server/linux64:$LD_LIBRARY_PATH +Type=simple +Restart=on-failure +RestartSec=10 +KillSignal=SIGINT +User=l4d2 +Group=l4d2 +WorkingDirectory=/home/l4d2/l4d2_server +ExecStart=/home/l4d2/l4d2_server/srcds_run -console -game left4dead2 -port 27015 +exec server.cfg +map c14m1_junkyard -insecure -debug +[Install] +WantedBy=multi-user.target +EOF" +sudo systemctl daemon-reload +sudo systemctl start l4d2.service +sudo journalctl -u l4d2 -f +``` + + +**Logs** + +Journal log: +``` +Mar 25 19:53:17 gamezserver systemd[1]: Started l4d2.service - L4D2 Dedicated Server. +Mar 25 19:53:17 gamezserver srcds_run[3454945]: Enabling debug mode +Mar 25 19:53:18 gamezserver srcds_run[3454945]: Server will auto-restart if there is a crash. +Mar 25 19:53:18 gamezserver srcds_run[3454956]: Setting breakpad minidump AppID = 222860 +Mar 25 19:53:18 gamezserver srcds_run[3454956]: Using breakpad crash handler +Mar 25 19:53:18 gamezserver srcds_run[3454956]: Forcing breakpad minidump interfaces to load +Mar 25 19:53:18 gamezserver srcds_run[3454956]: Looking up breakpad interfaces from steamclient +Mar 25 19:53:18 gamezserver srcds_run[3454956]: Calling BreakpadMiniDumpSystemInit +Mar 25 19:53:19 gamezserver srcds_run[3454956]: [S_API] SteamAPI_Init(): SteamAPI_IsSteamRunning() did not locate a running instance of Steam. +Mar 25 19:53:19 gamezserver srcds_run[3454956]: [S_API] SteamAPI_Init(): Loaded '/home/l4d2/.steam/sdk32/steamclient.so' OK. +Mar 25 19:53:19 gamezserver srcds_run[3454956]: #Using shader api: bin/shaderapiempty_srv.so +Mar 25 19:53:19 gamezserver srcds_run[3454956]: # +Mar 25 19:53:19 gamezserver srcds_run[3454956]: #Console initialized. +Mar 25 19:53:19 gamezserver srcds_run[3454956]: #Using breakpad minidump system +Mar 25 19:53:19 gamezserver srcds_run[3454956]: #Game_srv.so loaded for "Left 4 Dead 2" +Mar 25 19:53:19 gamezserver srcds_run[3454956]: Server is hibernating +Mar 25 19:53:19 gamezserver srcds_run[3454956]: ConVarRef test_progression_loop doesn't point to an existing ConVar +Mar 25 19:53:21 gamezserver srcds_run[3454956]: [S_API FAIL] SteamAPI_Init() failed; create pipe failed.Looking up breakpad interfaces from steamclient +Mar 25 19:53:21 gamezserver srcds_run[3454956]: Calling BreakpadMiniDumpSystemInit +Mar 25 19:53:22 gamezserver srcds_run[3454945]: Segmentation fault (core dumped) +Mar 25 19:53:22 gamezserver srcds_run[3455040]: BFD: warning: /home/l4d2/l4d2_server/core has a segment extending past end of file +Mar 25 19:53:22 gamezserver srcds_run[3455040]: warning: core file may not match specified executable file. +Mar 25 19:53:22 gamezserver srcds_run[3455040]: Failed to read a valid object file image from memory. +Mar 25 19:53:22 gamezserver srcds_run[3455040]: debug.cmds:5: Error in sourced command file: +Mar 25 19:53:22 gamezserver srcds_run[3455040]: No function contains program counter for selected frame. +Mar 25 19:53:22 gamezserver srcds_run[3454945]: email debug.log to linux@valvesoftware.com +Mar 25 19:53:22 gamezserver srcds_run[3454945]: Tue Mar 25 19:53:22 EDT 2025: Server restart in 10 seconds +``` + +debug.log: +``` +CRASH: Tue Mar 25 19:53:22 EDT 2025 +Start Line: ./srcds_linux -console -game left4dead2 -port 27015 +exec server.cfg +map c14m1_junkyard -insecure -debug +[New LWP 3454956] +[New LWP 3455015] +[New LWP 3455017] +Core was generated by `/usr/bin/FEXInterpreter ./srcds_linux ./srcds_linux -console -game left4dead2 -'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x000000037b3d9ea0 in ?? () +[Current thread is 1 (LWP 3454956)] +#0 0x000000037b3d9ea0 in ?? () +#1 0x00000003612e31fc in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +No symbol table info available. +x0 0x3cc90ab0 1019808432 +x1 0x0 0 +x2 0x78 120 +x3 0x648557df 1686460383 +x4 0x0 0 +x5 0x27f 639 +x6 0x1 1 +x7 0x0 0 +x8 0xff5f5bd0 4284439504 +x9 0xff5f5c08 4284439560 +x10 0x1 1 +x11 0x1 1 +x12 0xf08b5ed32788 264481382016904 +x13 0x36df52088 14729683080 +x14 0xffff 65535 +x15 0xffff 65535 +x16 0x1 1 +x17 0xf08b5e81c080 264481376682112 +x18 0x0 0 +x19 0x25 37 +x20 0x4 4 +x21 0xffffffffecbf5dc0 -323002944 +x22 0x7 7 +x23 0x1 1 +x24 0x3fff 16383 +x25 0x8000000000000000 -9223372036854775808 +x26 0xff5f5bc4 4284439492 +x27 0xa0a48f 10527887 +x28 0xf08b5dac70a0 264481362702496 +x29 0x2e 46 +x30 0x3612e31fc 14515319292 +sp 0xffffc7662d30 0xffffc7662d30 +pc 0x37b3d9ea0 0x37b3d9ea0 +cpsr 0xa0001000 [ EL=0 BTYPE=0 SSBS C N ] +fpsr 0x13 [ IOC DZC IXC ] +fpcr 0x1000000 [ Len=0 Stride=0 RMode=0 FZ ] +tpidr 0xf08b5ed32760 0xf08b5ed32760 +tpidr2 0x0 0x0 +No shared libraries loaded at this time. +End of Source crash report +``` + +**System information:** + - OS: Ubuntu 24.04 + - CPU/SoC: Server Neoverse-N1 aarch64 + - RootFS used: Ubuntu 24.04 Official Rootfs + - FEX version: FEX-2503 installed with the ppa (FEXGetConfig --version) + - Thunks Enabled: No, unless the ppa ships with a thunk + +**Additional context** + - Is this an x86 or x86-64 game: x86 + - This is a game server diff --git a/results/scraper/fex/4436 b/results/scraper/fex/4436 new file mode 100644 index 000000000..0957d2a6a --- /dev/null +++ b/results/scraper/fex/4436 @@ -0,0 +1,5 @@ +gcc test fails on HDK8650 +Commit 2f6f8b93e (PR #4424) breaks `pr88240.c.gcc-target-test-64.jit.gcc-target-64` on the HDK. Passes on the Lenovo T14s, which makes me think this is potentially SVE or RPRES related. + +Commit d48413cbe is the last passing commit. + diff --git a/results/scraper/fex/4459 b/results/scraper/fex/4459 new file mode 100644 index 000000000..14b2e84ff --- /dev/null +++ b/results/scraper/fex/4459 @@ -0,0 +1,3 @@ +How to use FEX in non-privileged container? +I’m using a containerized cloud server, but I don’t have full Linux privileges. This means I’m unable to use binfmt_misc or install new file systems like SquashFS. I want to run x86_64 software (specifically, StarCraft II via https://github.com/google-deepmind/pysc2) on an arm64-based system. Is there any possible workaround or solution? + diff --git a/results/scraper/fex/4480 b/results/scraper/fex/4480 new file mode 100644 index 000000000..632946eea --- /dev/null +++ b/results/scraper/fex/4480 @@ -0,0 +1,11 @@ +Optimize multiple stack push/pop in to ldp/stp +An optimization that we can do since we disable TSO emulation on stack accesses is to merge pushes and pops in to ldp and stp respectively. +This would allow performance improvements in almost every application since any function doing real work is going to push and pop the stack. + +An example that we already have in instrcountci is the `Sekiro spill block` function. This pushes and pops 8 GPRs to the stack coming in to the function and then eight again coming out. This is a total of 16 instructions today, but can be reduced to 8 instead. Just enough to reduce the full block size from 126 ARM instructions down to 118, one instruction less than the original x86 code count of 119. + +This is fairly trivial to implement, and should give a decent performance improvement since pair loadstore instructions are just as fast as non-paired on any ARM cpu cores that matter. + +Creating this tracking issue so we don't forget about it. + +Additional note, FEAT_LRCPC3 adds pair-wise push/pop instructions with x86 TSO memory model semantics. While we don't use TSO semantics on stack accesses today (Today's hardware aside from Apple's isn't good enough), once that extension is in any shipping hardware we should add support for it and a TSO toggle for stack accesses. Although this extension only added support for 32-bit and 64-bit pushes and pops, so 8-bit and 16-bit is left out. \ No newline at end of file diff --git a/results/scraper/fex/4483 b/results/scraper/fex/4483 new file mode 100644 index 000000000..0bbefaf9e --- /dev/null +++ b/results/scraper/fex/4483 @@ -0,0 +1,21 @@ +[ERROR] Couldn't connect to FEXServer socket 1001.FEXServer.Socket 111 +After updating fex-emu-armv8.4 from 2502 to 2504 on an Ubuntu 24.04 host, I get the following error when starting a game from Steam via muvm: +``` +[ERROR] Couldn't connect to FEXServer socket 1001.FEXServer.Socket 111 +[ERROR] Couldn't connect to FEXServer socket /run/user/1001/1001.FEXServer.Socket 2 +[ERROR] Couldn't connect to FEXServer socket 1001.FEXServer.Socket 111 +[ERROR] Couldn't connect to FEXServer socket /run/user/1001/1001.FEXServer.Socket 2 +[ERROR] Couldn't connect to FEXServer socket 1001.FEXServer.Socket 111 +[ERROR] Couldn't connect to FEXServer socket /run/user/1001/1001.FEXServer.Socket 2 +[ERROR] Couldn't connect to FEXServer socket 1001.FEXServer.Socket 111 +[ERROR] Couldn't connect to FEXServer socket /run/user/1001/1001.FEXServer.Socket 2 +[ERROR] Couldn't connect to FEXServer socket 1001.FEXServer.Socket 111 +[ERROR] Couldn't connect to FEXServer socket /run/user/1001/1001.FEXServer.Socket 2 +[ERROR] Couldn't connect to FEXServer socket 1001.FEXServer.Socket after launching the process +[ERROR] FEXServerClient: Failure to setup client +``` +Switching back to fex-emu-armv8.4 2502 makes it work again. + +RootFS is Ubuntu 24.10 based on https://github.com/kaazoo/RootFS/blob/main/Configs/Ubuntu_24_10_asahi.json + +Steam client version is 1743554648 (stable). \ No newline at end of file diff --git a/results/scraper/fex/4484 b/results/scraper/fex/4484 new file mode 100644 index 000000000..f0df34517 --- /dev/null +++ b/results/scraper/fex/4484 @@ -0,0 +1,5 @@ +Track stack accesses through register moves to remove more TSO accesses +It's common practice to do a `mov rbp, rsp` and some arithmetic on it and then access stack variables through rbp instead of rsp. +We should track those stack moves and delete TSO accesses when possible. + +This will have a disproportionately large improvement on Qualcomm's Orion which has stalls when a cacheline is accessed as LRCPC and then non-LRCPC, In addition to the other improvements that non-TSO memory accesses improve. \ No newline at end of file diff --git a/results/scraper/fex/4486 b/results/scraper/fex/4486 new file mode 100644 index 000000000..0f4125c5f --- /dev/null +++ b/results/scraper/fex/4486 @@ -0,0 +1,13 @@ +METAL GEAR RISING: REVENGEANCE Crash with multiblock enabled and x87 reduced precision disabled. +This game is usually capable of running, but when using full precision x87 and multiblock it seems like it crashes once reaching the title screen. It gets through its intro images. + +| Multiblock | Reduced Precision On | Reduced Precision Off | +| - | - | - | +| On | ✅Works | ❌Crashes | +| Off | ✅Works | ✅Works | + +https://store.steampowered.com/app/235460/METAL_GEAR_RISING_REVENGEANCE + +Couldn't bisect it far enough back since Multiblock was fairly sketchy a few months ago. + +(Looks like Mirror's Edge might have the same problem.) \ No newline at end of file diff --git a/results/scraper/fex/4493 b/results/scraper/fex/4493 new file mode 100644 index 000000000..33de414a5 --- /dev/null +++ b/results/scraper/fex/4493 @@ -0,0 +1,97 @@ +[ARM64EC] Steam on Wine has random crash in steamwebhelper +**FEX Version:** git head: 09e622d5a03d55e39ff81668ab08a6595ddc5c5b +**Wine Version**: Wine tag 10.5 + +### Log + +``` +097c:warn:seh:dispatch_exception "src\\common\\asyncfileiohandler.cpp (769) : dwRet != WAIT_FAILED\n" +097c:trace:seh:dispatch_exception code=40010006 (DBG_PRINTEXCEPTION_C) flags=0 addr=000000007A322339 +097c:trace:seh:dispatch_exception info[0]=0000000000000040 +097c:trace:seh:dispatch_exception info[1]=000000000FF9E900 +097c:trace:seh:dispatch_exception pc=0000007fff89b5c8 sp=0000000115ffee30 lr=0000000000000000 fp=000000007ac77000 +097c:trace:seh:dispatch_exception x0=0000000000000000 x1=000000000ff9e428 x2=0000000000000001 x3=00000001038bba90 +097c:trace:seh:dispatch_exception x4=0000000115fff160 x5=0000000000000000 x6=000000000ece2000 x7=000000007a851cec +097c:trace:seh:dispatch_exception x8=0000000000000090 x9=0000000000005d17 x10=00000000000001e0 x11=0000000100210000 +097c:trace:seh:dispatch_exception x12=00000000000000b0 x13=00000000000011d1 x14=000000000ff9e404 x15=000000000ff9e418 +097c:trace:seh:dispatch_exception x16=0000007fffa13210 x17=0000000115fff1f0 x18=000000000ece0000 x19=000000000ff9e700 +097c:trace:seh:dispatch_exception x20=000000000ff9e428 x21=0000000000000001 x22=00000001038ce3e0 x23=0000000115fffd20 +097c:trace:seh:dispatch_exception x24=0000000000000001 x25=000000007ac78000 x26=0000000000000246 x27=000000007ac78002 +097c:trace:seh:dispatch_exception x28=0000000115fff2d0 cpsr=20000000 fpcr=00000000 fpsr=00000000 +097c:trace:seh:call_seh_handlers calling handler 0000007FFF89B5E0 (rec=0000000115FFED70, frame=115fff1f0 context=0000000115FFE9C0, dispatch=0000000115FFE5F8) +097c:trace:seh:RtlUnwindEx code=40010006 flags=2 end_frame=0000000115FFF1F0 target_ip=0000007FFF89B5BC +097c:trace:seh:RtlUnwindEx info[0]=0000000000000040 +097c:trace:seh:RtlUnwindEx info[1]=000000000ff9e900 +097c:trace:seh:RtlUnwindEx pc=0000007fffa13e60 sp=0000000115ffd8d0 lr=0000000000000000 fp=0000007fffabc1a0 +097c:trace:seh:RtlUnwindEx x0=0000000000000000 x1=0000007fff89b5bc x2=0000000115ffed70 x3=0000000115ffe5f8 +097c:trace:seh:RtlUnwindEx x4=0000000115ffde80 x5=0000000000000000 x6=0000000115fff1f0 x7=0000000115ffe9c0 +097c:trace:seh:RtlUnwindEx x8=0000000115fff1f0 x9=0000000060000000 x10=0000000115eff890 x11=0000000000000000 +097c:trace:seh:RtlUnwindEx x12=0000000000000031 x13=000000000000009b x14=0000007fffb00000 x15=0000007fffab6330 +097c:trace:seh:RtlUnwindEx x16=0000007fffa21b74 x17=0000007fffa199ec x18=000000000ece0000 x19=00000000c0000144 +097c:trace:seh:RtlUnwindEx x20=0000000115ffde80 x21=0000000115ffe9c0 x22=0000000115ffed70 x23=0000000115fff1f0 +097c:trace:seh:RtlUnwindEx x24=0000000000000000 x25=0000007fff89b5bc x26=0000000115ffe5f8 x27=0000007fffb00000 +097c:trace:seh:RtlUnwindEx x28=0000007fffabc1e8 cpsr=40000000 fpcr=00000000 fpsr=00000000 +097c:trace:seh:RtlUnwindEx calling handler 0000007FFF9E5CF4 (rec=0000000115FFED70, frame=115ffe240 context=0000000115FFDE80, dispatch=0000000115FFDC98) +097c:trace:seh:RtlUnwindEx handler 0000007FFF9E5CF4 returned 1 +097c:trace:seh:RtlUnwindEx calling handler 0000007FFF89B5E0 (rec=0000000115FFED70, frame=115fff1f0 context=0000000115FFDE80, dispatch=0000000115FFDC98) +097c:trace:seh:RtlUnwindEx handler 0000007FFF89B5E0 returned 1 +097c:trace:seh:RtlRestoreContext returning to 7fff89b5bc stack 115ffee30 +097c:trace:seh:RtlGetExtendedContextLength2 context_flags 0x1003f, length 0000000115FFEB14, compaction_mask ffffffffffffffff. +097c:trace:seh:RtlInitializeExtendedContext2 context 000000000FF9E418, context_flags 0x1003f, context_ex 0000000115FFEB18, compaction_mask ffffffffffffffff. +097c:warn:seh:dispatch_exception "src\\common\\asyncfileiohandler.cpp (769) : dwRet != WAIT_FAILED\n" +097c:trace:seh:dispatch_exception code=40010006 (DBG_PRINTEXCEPTION_C) flags=0 addr=7A322339 +097c:trace:seh:dispatch_exception info[0]=00000040 +097c:trace:seh:dispatch_exception info[1]=0FF9E900 +097c:trace:seh:dispatch_exception eip=7a322339 esp=0ff9e700 ebp=0ff9e754 eflags=00000246 +097c:trace:seh:dispatch_exception eax=0ff9e700 ebx=00000002 ecx=00000008 edx=0ff9e898 +097c:trace:seh:dispatch_exception esi=00000002 edi=0ff9e900 cs=0023 ds=002b es=002b fs=0053 gs=002b ss=002b +097c:trace:seh:call_vectored_handlers calling handler at 77B3DBE0 code=40010006 flags=0 +097c:trace:seh:call_vectored_handlers handler at 77B3DBE0 returned 0 +097c:trace:seh:call_seh_handlers calling handler at 7A755980 code=40010006 flags=0 +097c:trace:seh:__regs_RtlUnwind code=40010006 flags=2 +097c:trace:seh:__regs_RtlUnwind eip=7a755972 esp=0ff9e1ac ebp=0ff9e1b4 eflags=00000212 +097c:trace:seh:__regs_RtlUnwind eax=00000000 ebx=0ff9e76c ecx=0ff9e3c8 edx=0ff9e76c +097c:trace:seh:__regs_RtlUnwind esi=00000001 edi=0ff9e3c8 cs=0023 ds=002b es=002b fs=0053 gs=002b ss=002b +097c:trace:seh:__regs_RtlUnwind calling handler at 7BE1AF50 code=40010006 flags=2 +097c:trace:seh:__regs_RtlUnwind handler at 7BE1AF50 returned 1 +03f8:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=0000007ED944B016 +03f8:trace:seh:dispatch_exception info[0]=0000000000000001 +03f8:trace:seh:dispatch_exception info[1]=0000007B203E3000 +03f8:trace:seh:dispatch_exception rip=0000007ed944b016 rsp=0000007b07a4f448 rbp=0000007b203e2730 eflags=00000202 +03f8:trace:seh:dispatch_exception rax=0000007b203e2730 rbx=0000006407a8c000 rcx=0000007b203e2f40 rdx=0000007b20500d80 +03f8:trace:seh:dispatch_exception rsi=0000000000000c40 rdi=0000007b203e2731 r8=0000000000000430 r9=fffffffffffffff0 +03f8:trace:seh:dispatch_exception r10=0000007ed58a0000 r11=0000000000000000 r12=0000007b20500571 r13=0000006408a67a58 +03f8:trace:seh:dispatch_exception r14=0000000000000003 r15=0000007b20500570 mxcsr=00001fa5 +03f8:trace:seh:call_vectored_handlers calling handler at 0000007ED648D3D0 code=c0000005 flags=0 +03f8:trace:seh:call_vectored_handlers handler at 0000007ED648D3D0 returned 0 +03f8:trace:seh:call_vectored_handlers calling handler at 0000007ED4D69A10 code=c0000005 flags=0 +03f8:trace:seh:call_vectored_handlers handler at 0000007ED4D69A10 returned 0 +03f8:trace:seh:call_seh_handlers calling handler 0000007FFFA3F47C (rec=0000007B07A4F390, frame=7b07a50000 context=0000007B07A4EB10, dispatch=0000007B07A4E748) +**wine: Unhandled page fault on write access to 0000007B203E3000 at address 0000007ED944B016 (thread 03f8), starting debugger...** +03f8:trace:seh:start_debugger Starting debugger L"winedbg --auto 864 756" +0154:trace:seh:RtlUnwindEx code=80000026 flags=2 end_frame=00000001001FEF00 target_ip=0000007FFF89C698 +0154:trace:seh:RtlUnwindEx info[0]=00000001001fede0 +0154:trace:seh:RtlUnwindEx pc=0000007fffa13e60 sp=00000001001fd840 lr=0000000000000000 fp=000000007ac77000 +0154:trace:seh:RtlUnwindEx x0=0000000000000000 x1=0000007fff89c698 x2=00000001001fe198 x3=0000000000000001 +0154:trace:seh:RtlUnwindEx x4=00000001001fddf0 x5=0000000000000000 x6=0000001000000003 x7=000000007a851cec +0154:trace:seh:RtlUnwindEx x8=00000001001fef00 x9=0000000000000001 x10=00000001001ff148 x11=0000000000000000 +0154:trace:seh:RtlUnwindEx x12=0000000000000000 x13=0000000074a0aa80 x14=000000000012ede8 x15=000000000012edfc +0154:trace:seh:RtlUnwindEx x16=0000007fff89c258 x17=0000000074a0aa40 x18=000000007ffc0000 x19=0000000100206910 +0154:trace:seh:RtlUnwindEx x20=00000001001fddf0 x21=000000007ac76000 x22=00000001001fe198 x23=00000001001fef00 +0154:trace:seh:RtlUnwindEx x24=000000007ffc2000 x25=0000007fff89c698 x26=0000000000200242 x27=000000007ac78002 +0154:trace:seh:RtlUnwindEx x28=00000001001fe310 cpsr=60000000 fpcr=00000000 fpsr=00000010 +0154:trace:seh:RtlUnwindEx calling handler 0000007FFF89B640 (rec=00000001001FE198, frame=1001fe260 context=00000001001FDDF0, dispatch=00000001001FDC08) +0154:trace:seh:RtlUnwindEx handler 0000007FFF89B640 returned 1 +0154:trace:seh:RtlUnwindEx calling handler 0000007FFF89B690 (rec=00000001001FE198, frame=1001fe800 context=00000001001FDDF0, dispatch=00000001001FDC08) +0154:trace:seh:RtlUnwindEx handler 0000007FFF89B690 returned 1 +0154:trace:seh:RtlRestoreContext returning to 7fff89c698 stack 1001fe800 +``` + + +And i found there is lots of "src\\common\\asyncfileiohandler.cpp (769) : dwRet != WAIT_FAILED" exception throw, and catching backtrace via winedbg and winedbg will crash. + +I don't know if it's wine issue or FEX issue. + +You can reproduce this issue on Hangover, running steam with cef breakpad disable `"steam -cef-disable-breakpad -disable-winh264"`。after login and waiting a little bit, do something and it will be crashed. + +It's working normal when using box64 + x86 wine. \ No newline at end of file diff --git a/results/scraper/fex/4496 b/results/scraper/fex/4496 new file mode 100644 index 000000000..621bf0422 --- /dev/null +++ b/results/scraper/fex/4496 @@ -0,0 +1,39 @@ +WarThunder: Random hang ups +**What Game** +[WarThunder](https://warthunder.com/en/) + +**Describe the bug** +Game seems to hang after a bit of playtime? +Very inconsistent but seems to happen more frequently in ground battles/ground test drives. + +**To Reproduce** +Steps to reproduce the behavior: +1. Download the game +2. Test drive a tank or join a real match +3. Play a little +4. Game suddenly locks up + +**Expected behavior** +Game should not lock up, Or at least show an error? + +**System information:** + - OS: Artix Linux + - CPU/SoC: Cix CD8180 + - Video driver version: OpenGL ES 3.2 Mesa 25.1.0-devel (git-a530890e75) + - RootFS used: ARMtix linux + - FEX version: FEX-2501 + - Thunks Enabled: ? (Unlikely? No?) + +**Additional context** + - Is this an x86 or x86-64 game: x86-64 + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Yes + - Is this a Vulkan game: Yes + - If Yes, What is your Vulkan driver: radav + +Add any other context about the problem here. +This is ran on a Radxa Orion O6 using ARMtix linux & ACPI boot with mainline linux 6.15-rc1. +I'm also running this with an RX 580 since the onboard GPU does not have mesa drivers yet. +There are no errors, Game just hangs for some reason after a bit of playtime, No idea why and i've tried changing basically every setting in FEXConfig.. + +Last i checked this wasn't an issue on SDM845 (My OnePlus 6T) +I was able to play there for quite a while without issues. \ No newline at end of file diff --git a/results/scraper/fex/4502 b/results/scraper/fex/4502 new file mode 100644 index 000000000..518fd58f9 --- /dev/null +++ b/results/scraper/fex/4502 @@ -0,0 +1,24 @@ +Question: How to properly use software renderer (OSMesa) with FEX-Emu for StarCraft II? +Hi team, + +I'm currently using FEX-Emu to run the Linux `x86_64` version of StarCraft II (using the game binaries provided in the [`[Blizzard/s2client-proto](https://github.com/Blizzard/s2client-proto)`](https://github.com/Blizzard/s2client-proto) repository). I'm trying to run the game with software rendering by passing the `-osmesapath` parameter, pointing to the following library: + +``` +/usr/lib/x86_64-linux-gnu/libOSMesa.so.8 +``` + +Since I'm using software rendering, does this mean the x86 version of the OSMesa library will be used and executed via FEX? + +In an attempt to improve rendering speed, I tried replacing the library with the native AArch64 version: + +``` +/usr/lib/aarch64-linux-gnu/libOSMesa.so.8 +``` + +However, when doing so, the game fails to load the library properly. + +What is the correct way to use OSMesa with FEX-Emu in this scenario? Is there a way to benefit from the native AArch64 OSMesa for better performance, or must I stick with the x86 version? + +Any guidance would be greatly appreciated! + +Thanks! \ No newline at end of file diff --git a/results/scraper/fex/4507 b/results/scraper/fex/4507 new file mode 100644 index 000000000..5719fe25b --- /dev/null +++ b/results/scraper/fex/4507 @@ -0,0 +1,4 @@ +FEXConfig layout issues with Qt 6.9 +The update from Qt 6.8 to 6.9 introduced weird padding at the top of FEXConfig's tab contents: + + \ No newline at end of file diff --git a/results/scraper/fex/4514 b/results/scraper/fex/4514 new file mode 100644 index 000000000..6c446940e --- /dev/null +++ b/results/scraper/fex/4514 @@ -0,0 +1,10 @@ +CodeBuffer management long-term planning +#4479 is laying the ground work to restructure CodeBuffer handling for on-disk code caching, however there are more changes that are worth working on in the future. + +Here's a list of ideas: +* [ ] Preserve old CodeBuffer data on resize by relocation +* [ ] Detect and discard stale CodeBuffer versions more eagerly (i.e. before new code is compiled) +* [ ] Use dedicated CodeBuffer for ephemeral compilation (TSO automigration, SMC, TF, CompileSingleStep) +* [ ] Re-enable parallel compiler backend operation by compiling to temp CodeBuffer and relocating it +* [ ] Use smarter underlying CodeBuffer data structures to share memory allocations between versions +* [ ] Improve code invalidation logic for self-modifying code (currently will just keep growing the buffers) diff --git a/results/scraper/fex/4520 b/results/scraper/fex/4520 new file mode 100644 index 000000000..234016401 --- /dev/null +++ b/results/scraper/fex/4520 @@ -0,0 +1,4 @@ +Library Forwarding: Provide wl_list_init replacement for libdecor +This breaks use of host `libwayland-client`. The list APIs will need to be implemented guest-side to preserve 32-bit support. + +The issue can be reproduced by launching Super Meat Boy from within Steam. diff --git a/results/scraper/fex/4526 b/results/scraper/fex/4526 new file mode 100644 index 000000000..2ea383e40 --- /dev/null +++ b/results/scraper/fex/4526 @@ -0,0 +1,20 @@ +Gravel game uses broken SSL with SHA +This is due to an old OpenSSL issue reported at https://github.com/openssl/openssl/issues/23144 + +The Windows build of [Gravel](https://store.steampowered.com/app/558260/Gravel/) currently crashes under FEX. This is due to a bug in old versions of OpenSSL where if SHA1 was supported then OpenSSL would hit a code path that was broken. In this case this code path should be hit unconditionally as long as the host CPU supports SSSE3 and SHA, the AVX code code path is only run if SHA isn't a supported extensions. OpenSSL is statically compiled in to the game, so it will always have this broken code path unless the game devs come back and update their game. + +The weird thing is that running this same code under Proton on my AMD system, the game runs, and my AMD system definitely supports SHA. Additional weirdness, this game also runs on Windows+Intel without issue. Additional+Additional weirdness, if FEX's CPUID is changed over to AMD style, then this game runs. + +The CPUID value that is checked for SHA lives at address `0x144333f28`, this ends up being 0 on my AMD system, but it ends up being cpuid function_7.ebx under FEX. + +The RIP of the block that sets this value to 0 is: 0x140006df0 +Then the RIP that sets it 0x218827E9 is: 0x140006eec +This is the expected outcome. + +BUT when FEX is set to `AuthenticAMD` then the second write gets skipped (Potentially similar to how my desktop is ending up with zero initialized value?) + +Ideally I could have gdb attached to the process at start on my x86 desktop and watch the value as well, but `PROTON_WAIT_ATTACH` isn't really working there. + +Maybe there is some bug in OpenSSL's old CPUID code that it never actually ends up reading func_07.ebx, but a bug in FEX's flag handling or something causes it to execute the code? + +Really annoying issue. \ No newline at end of file diff --git a/results/scraper/fex/4535 b/results/scraper/fex/4535 new file mode 100644 index 000000000..916cee444 --- /dev/null +++ b/results/scraper/fex/4535 @@ -0,0 +1,9 @@ +Work towards reducing codegen for Interpreter fallbacks +Remove the ABI spilling and everything from the JIT blocks themselves and move it to the Dispatcher. Will alleviate some of the problems that #4486 is hitting but not expected to remove it. + +A bit counter-intuitively, generating a bunch of ABI handling code inline in the JIT is actually /worse/ for performance than one might expect. It's actually better to generate all this code in the dispatcher, and then eat an additional branch to jump to it instead. This is something that I found out years ago in the Dolphin JIT. +In a multithreaded environment (without code sharing) it also means that we only have this ABI handling consuming cachelines from one memory region, making it more likely to already be in L2 for cores. + +I already started working towards this a couple months ago when I was keeping FPRs in vector registers for ABI calls, which reduces the burden of putting things in GPRs (especially because of win32 ABI). + +Basic gist is to move all the ABI handling for the 16 different fallback ABIs to the dispatcher, and then the JIT only needs to do some /very/ minor work instead. This'll cut the number of instructions that the JIT needs to emit from 34-60ish to something like less than a dozen? Haven't implemented it yet so I don't have hard numbers yet. \ No newline at end of file diff --git a/results/scraper/fex/4548 b/results/scraper/fex/4548 new file mode 100644 index 000000000..ff7b7235e --- /dev/null +++ b/results/scraper/fex/4548 @@ -0,0 +1,78 @@ +Question/Request: FEX x87 reduced precison info and comparison vs new "rosettax87" project hack? +Hi, +just very new to FEX and finding that FEX supports some kind of x87 reduced precision.. + +searching google I find references everywhere but not much info: +a)https://www.reddit.com/r/AsahiGaming/comments/1hv1cix/games_that_perform_better_with_reduced_x87/ +b)https://fex-emu.com/FEX-2310/: +"Until then it is recommended to use FEX’s x87 reduced precision mode to try and alleviate some of the overhead." +c)https://fex-emu.com/FEX-2503/ +"This allows to to see that maybe we should try enabling the x87 reduced precision option to get some performance back." + +and in some forum I found: +FEX_X87REDUCEDPRECISION=1 +so that's the enviroment variable to add, right? + +also what perf can we gain vs non reduced on targeted microtests? what kind of reduction precision loss? +sorry if I don't know where to search for docs.. + +I say this because for Rosetta since recently we have project: +https://github.com/Lifeisawful/rosettax87 +which acceleretes x87 computation in some cases 10X at least on M4: +https://github.com/Lifeisawful/rosettax87/issues/2 + +at least on this simple shared benchmark calculation fsqrt seems: +clang -v -arch x86_64 -mno-sse -mfpmath=387 ./sample/math.c -o ./build/math + +at least +Rosetta M4: + Average time: 123040 ticks + +Rosettax87 M4: + Average time: 12222 ticks + + +part of code: +``` +#define TIMES 1000000 +#define RUNS 10 +#define METHOD run_fsqrt + +clock_t run_fsqrt() { + float sixteen = 16.0f; + + clock_t start = clock(); + + // Run fsqrt many times to get measurable time + float four; + for(int i = 0; i < TIMES; i++) { + four = __builtin_sqrtf(sixteen); + } + + clock_t end = clock(); + clock_t time_spent = (end - start); + + printf("Result: %x\n", *(uint32_t*)&four); + return time_spent; +} + +int main() { + clock_t times[RUNS]; + clock_t sum = 0; + + printf("benchmark %s\n", STRINGIFY(METHOD)); + + // Perform multiple runs + for(int i = 0; i < RUNS; i++) { + times[i] = METHOD(); + sum += times[i]; + printf("Run %d time: %lu ticks\n", i+1, times[i]); + } + + // Calculate average using integer math + clock_t avg = sum / RUNS; + printf("\nAverage time: %lu ticks\n", avg); + + return 0; +} +``` \ No newline at end of file diff --git a/results/scraper/fex/455 b/results/scraper/fex/455 new file mode 100644 index 000000000..057ad1052 --- /dev/null +++ b/results/scraper/fex/455 @@ -0,0 +1,6 @@ +Performance CI Load testing +We need CI performance benchmarking. + +https://github.com/marketplace/actions/continuous-benchmark +https://k6.io/blog/load-testing-using-github-actions +https://docs.gitlab.com/ee/user/project/merge_requests/load_performance_testing.html \ No newline at end of file diff --git a/results/scraper/fex/4550 b/results/scraper/fex/4550 new file mode 100644 index 000000000..67f544a60 --- /dev/null +++ b/results/scraper/fex/4550 @@ -0,0 +1,3 @@ +Crysis 2 Maximum edition: Crashes with multiblock enabled +Seems to be some sort of cache invalidation issue? +Seemingly jumps to 0x1d9200a which is used for little trampolines or something and doesn't exist in the executable and then crashes out with a SIGSEGV. \ No newline at end of file diff --git a/results/scraper/fex/4552 b/results/scraper/fex/4552 new file mode 100644 index 000000000..fb2d53901 --- /dev/null +++ b/results/scraper/fex/4552 @@ -0,0 +1,63 @@ +DUET: exception spam and crash after few mins +**What Game** +DUET +https://store.steampowered.com/app/3394250/DUET/ + +Note: The game is quite short. + +**Describe the bug** +Day 2 in the game it appears to hang forever and eventually crashes. + +Enabling proton logging, there is about 100MB of dispatching exceptions like this: +``` +2516.598:0128:012c:warn:seh:dispatch_exception backtrace: --- Exception 0xc0000005. +2516.598:0128:012c:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=00000000683D5E06 +2516.598:0128:012c:trace:seh:dispatch_exception info[0]=0000000000000000 +2516.598:0128:012c:trace:seh:dispatch_exception info[1]=000000003D3CEF17 +2516.598:0128:012c:trace:seh:dispatch_exception rip=00000000683d5e06 rsp=000000000010e4c0 rbp=000000003d3cef27 eflags=00000246 +2516.598:0128:012c:trace:seh:dispatch_exception rax=0000000067e4ab40 rbx=0000000000000000 rcx=0000000000000004 rdx=0000000000001a0c +2516.598:0128:012c:trace:seh:dispatch_exception rsi=0000000067e4a280 rdi=00000000615d98a0 r8=0000000067e4ab40 r9=00006ffffbb25680 +2516.598:0128:012c:trace:seh:dispatch_exception r10=0000000000000000 r11=00006ffffb5dfb60 r12=000000000010ea50 r13=000000000010ebe0 +2516.598:0128:012c:trace:seh:dispatch_exception r14=00000000615c2d20 r15=0000000067951f30 mxcsr=00000000 +2516.598:0128:012c:trace:seh:call_vectored_handlers calling handler at 00006FFFFAF8B1B0 code=c0000005 flags=0 +2516.598:0128:012c:trace:seh:call_vectored_handlers handler at 00006FFFFAF8B1B0 returned 0 +2516.598:0128:012c:trace:seh:call_vectored_handlers calling handler at 00006FFFFACDC0A0 code=c0000005 flags=0 +2516.598:0128:012c:trace:seh:call_vectored_handlers handler at 00006FFFFACDC0A0 returned 0 +2516.598:0128:012c:trace:seh:call_vectored_handlers calling handler at 00006FFFFB845980 code=c0000005 flags=0 +``` + +And it ends with +``` +2560.304:0128:012c:warn:seh:dispatch_exception stack overflow 1856 bytes addr 0x6ffffff9ee84 stack 0x208c0 (0x20000-0x21000-0x120000) +ERROR: ld.so: object '/tmp/pressure-vessel-libs-V2QB62/${LIB}/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. +2561.464:021c:0220:trace:seh:install_bpf Installing seccomp filters. +2561.464:021c:0220:err:seh:install_bpf prctl(PR_SET_SECCOMP, ...): Invalid argument. +``` + +**To Reproduce** +Steps to reproduce the behavior: +1. Launch game. +2. Play for a few mins till day 2 +3. White screen appears for about 1 min as the proton log dumps about 100 MB of exception warnings. +4. Game crashes + +**Expected behavior** +Testing on an x86_64 machine, the entire game is playable under proton, so this is likely not a proton bug. + +**Screenshots and Video** +A white screen, so probably not worth wasting bandwidth. + +**System information:** + - OS (Host): `Linux verdigris 6.14.2-401.asahi.fc41.aarch64+16k #1 SMP PREEMPT_DYNAMIC Wed Apr 16 12:08:23 UTC 2025 aarch64 GNU/Linux` + - CPU/SoC: Apple M2 (under muvm) + - Video driver version:a Mesa 25.1.0-asahi20250221 + - RootFS used: DNF says `fex-emu-rootfs-fedora.noarch 42^0~20241209.2006-1.fc41` + - FEX version: returns nothing when running it under muvm? dnf reports `fex.aarch64 2.0.0-20.fc41` + - Thunks Enabled: Unsure, FEXGetConfig does not appear to return anything + +**Additional context** + - Is this an x86 or x86-64 game: x86-64 + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested (DX11 via Honeykrisp per proton logs) + - Is this a Vulkan game: No + +This appears to be a unity game as well. \ No newline at end of file diff --git a/results/scraper/fex/4556 b/results/scraper/fex/4556 new file mode 100644 index 000000000..d7a74600d --- /dev/null +++ b/results/scraper/fex/4556 @@ -0,0 +1,54 @@ +God of War Ragnarök crashes due to newer Playstation PC SDK +This is a bit of a tricky one since it seems to be restricted to this single statically linked library inside the application. +"Something" changed with the PSPC_SDK with Ragnarök to obfuscate this component and introduce a nasty state machine that breaks FEX. + +Some things of note that I discovered while trying to figure out why it crashes. +- It needs full precision x87 + - It's abusing FP operations to ensure that the result is producing exactly the correct results + - Might be an anti-emulation feature + - If reduced precision is enabled then it generates a broken pointer that it tries to dereference inside of strlen +- Once reduced precision is disabled, it actually runs through the state machine a bit. + - Every entrypoint uses a self-intersecting jump to try and confuse disassemblers + - Binaryninja doesn't care about this and just shows correct enough code + - Probably an obfuscation step for IDA or Ghidra +- Each entrypoint uses a custom ABI to try and confuse static analysis tools + - Arguments seem to be on the stack +- Most entrypoints **pop** things off the stack, which is something like the caller knows the trampolines branch target and pushes it before calling or something? + +Seemingly the entrypoint to the state machine from GoWR. Showing off the self-intersecting branch. Internal trampolines will use conditional branches that are self interesting. If the condition flags are wrong then they'll execute code incorrectly. + + +**Hopefully** this is just an abuse of CPU flags and we're just messing one of them up somewhere, but due to the obfuscation and trampolines it is hard to see exactly wtf is going on. + +If x87 reduced precision is not enabled then the state machine exits at some point with an opaque error and the game exits. + + + +We should also test this game on Windows On ARM to see if their emulator is good enough to handle this game. + +### Additional games that need to be tested after this game's launch +My concern is that games released after GoWR will have the same problems, but I haven't tested Playstation published games in a few months. If this is going to be a continuous thing or just a one-off for Ragnarök is currently unknown. + +- [❌] [Until Dawn](https://steamdb.info/app/2172010/) + - Crashes with x87 reduced precision enabled, but continues once disabled. + - Same weirdo self-intersecting branches. + + + - Can't get further than the menus since my Playstation Account is bugged. +- [❌] [Horizon Zero Dawn Remastered](https://steamdb.info/app/2561580/) + - Doesn't quite behave like Until Dawn, if x87 reduced precision is enabled then it just hangs. + - Once disabled the game continues fine. +- [❌] [Lego Horizon Adventures](https://steamdb.info/app/2428810/) + - The thing ships EOS, which I'm not even going to mess with. +- [❌] [Marvel's Spider-Man 2](https://steamdb.info/app/2651280/) + - Matches behaviour of Until Dawn +- [❌] [Midnight Murder Club](https://steamdb.info/app/2698870/) + - Matches behaviour of Until Dawn + - Additional quirk that once on the title screen it just claims network error + - Might be because of its Wine/Proton deetection. +- [❌] [The Last of Us Part II Remastered](https://steamdb.info/app/2531310/) + - Behaviour matches Until Dawn +- [ ] [Stellar Blade](https://steamdb.info/app/3489700/) (Releases in June 2025) (Has Denuvo, needs arm64ec testing) +- [ ] [Lost Soul Aside](https://steamdb.info/app/3378960/) (Releases in August 2025) +- [✅] [Days Gone Broken Road DLC?](https://steamdb.info/app/3238470/) + - Game works fine with DLC enabled. \ No newline at end of file diff --git a/results/scraper/fex/4557 b/results/scraper/fex/4557 new file mode 100644 index 000000000..8bfddd2c8 --- /dev/null +++ b/results/scraper/fex/4557 @@ -0,0 +1,26 @@ +`VMA Tracking corruption` is a vengeful spirit +I have been getting hit by this hard recently. It seems to occur fairly frequently with Steam when it is hammering a big game download. +In my case I'm hitting it with `Spider-Man 2` quite consistently. + +Backtrace: +``` +#0 FEXCore::Assert::ForcedAssert () at /mnt/Work/Work/work/FEXNew/FEXCore/Source/Utils/ForcedAssert.cpp:9 +9 asm volatile("hlt #1"); +[Current thread is 1 (Thread 0xc1438cc0 (LWP 72746))] +(gdb) bt +#0 FEXCore::Assert::ForcedAssert () at /mnt/Work/Work/work/FEXNew/FEXCore/Source/Utils/ForcedAssert.cpp:9 +#1 0x0000aaaae53d8be0 in LogMan::Throw::MFmt (fmt=<optimized out>, args=...) at /mnt/Work/Work/work/FEXNew/FEXCore/Source/Utils/LogManager.cpp:29 +#2 0x0000aaaae52dd964 in LogMan::Throw::AFmt<>(bool, char const*) (Value=<optimized out>, fmt=<optimized out>) at /mnt/Work/Work/work/FEXNew/FEXCore/include/FEXCore/Utils/LogManager.h:53 +#3 FEX::HLE::SyscallHandler::TrackMremap (this=0xffff94622000, Thread=0x48e88b000, OldAddress=3100446720, OldSize=<optimized out>, NewSize=<optimized out>, flags=1, NewAddress=2937729024) at /mnt/Work/Work/work/FEXNew/Source/Tools/LinuxEmulation/LinuxSyscalls/SyscallsSMCTracking.cpp:283 +#4 0x0000aaaae52ea724 in FEX::HLE::x32::RegisterMemory(FEX::HLE::SyscallHandler*)::$_4::operator()(FEXCore::Core::CpuStateFrame*, void*, unsigned long, unsigned long, int, void*) const (Frame=0x48e88b0a0, old_address=0xb8cd1000, old_size=806912, new_size=1052672, flags=1, new_address=<optimized out>, this=<optimized out>) at /mnt/Work/Work/work/FEXNew/Source/Tools/LinuxEmulation/LinuxSyscalls/x32/Memory.cpp:95 +#5 FEX::HLE::x32::RegisterMemory(FEX::HLE::SyscallHandler*)::$_4::__invoke(FEXCore::Core::CpuStateFrame*, void*, unsigned long, unsigned long, int, void*) (Frame=0x48e88b0a0, old_address=0xb8cd1000, old_size=806912, new_size=1052672, flags=1, new_address=<optimized out>) at /mnt/Work/Work/work/FEXNew/Source/Tools/LinuxEmulation/LinuxSyscalls/x32/Memory.cpp:95 +#6 0x00000005f53f3ecc in ?? () +#7 0x000000048e882000 in ?? () +#8 0x0001010000000100 in ?? () +``` + +Without assertions enabled it of course just results in a crash. + +Once the game is downloaded, it seems fine enough. The `ThreadedValidation` step doesn't seem to cause problems. + +This bug has also been around for a few months, so it's not a recent regression. \ No newline at end of file diff --git a/results/scraper/fex/4558 b/results/scraper/fex/4558 new file mode 100644 index 000000000..0c85a3f23 --- /dev/null +++ b/results/scraper/fex/4558 @@ -0,0 +1,29 @@ +(FEX-2505 Regression) Steam fails to launch +What game: +Steam (the store itself) +Describe the bug +Fails to launch with last error being +``` +*** longjmp causes uninitialized stack frame ***: terminated +``` +To Reproduce +`FEXInterpreter /usr/bin/steam -cef-force-occlusion -cef-force-opaque-backgrounds -no-cef-sandbox` + +Expected behavior +It should launch + +System information: + + OS: Gentoo Linux + CPU/SoC: Apple M1 Pro + Video driver version: Asahi Mesa 20250425 + RootFS used: Gentoo RootFS with Asahi Mesa overlayed (build 20250425) + FEX version: FEX-2505 + Thunks Enabled: No + +Additional context + + Is this an x86 or x86-64 game: Mixed pile of both x86 and x86-64 code + Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Unknown + Is this a Vulkan game: No/Not applicable + If Yes, What is your Vulkan driver: Honeykrisp diff --git a/results/scraper/fex/4568 b/results/scraper/fex/4568 new file mode 100644 index 000000000..235df21d4 --- /dev/null +++ b/results/scraper/fex/4568 @@ -0,0 +1,150 @@ +Counter-Strike 2 Dedicated Server: Segmentation fault during init on ARM Ampere A1 +**What Game** +Counter-Strike 2 Dedicated Server + +I installed `steamcmd` based on maual from here: https://developer.valvesoftware.com/wiki/SteamCMD +I installed CS2 using this script: +``` +#!/bin/sh +export LD_LIBRARY_PATH="~/games/steamcmd/linux32:$LD_LIBRARY_PATH" +export CPU_MHZ="2000" +FEXBash '~/games/steamcmd/steamcmd.sh +@ShutdownOnFailedCommand 1 +@NoPromptForPassword 0 +force_install_dir ~/games/cs2 +login <REDACTED_STEAM_USER> +app_update 730 +quit' +``` + +**Describe the bug** +When I try to run Counter Strike 2 Dedicated Server using this script: +``` +#!/bin/bash + +export LD_LIBRARY_PATH="~/steam/linux32:$LD_LIBRARY_PATH" +export CPU_MHZ="2000" +FEXInterpreter ~/games/cs2/game/bin/linuxsteamrt64/cs2 -dedicated -usercon -console +game_type 0 +game_mode 1 +ip 0.0.0.0 -port 27015 +map de_dust2 -maxplayers "10" +``` + +I got segmentation fault: +``` +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libengine2.so, got 0x55663e656fa0 + +Console initialized. +Steam AppId(730), BreakpadId(2347771) +InitSteamLogin_Internal: Initializing breakpad. +Using breakpad crash handler +Steam Universe is invalid, possibly asking before Steam was successfully initialized. +ResetBreakpadAppId: Universe is 0 (k_EUniverseInvalid) +ResetBreakpadAppId: Setting dedicated server app id: 2347773 +Setting breakpad minidump AppID = 2347773 +Forcing breakpad minidump interfaces to load +Looking up breakpad interfaces from steamclient +Calling BreakpadMiniDumpSystemInit +Loaded libSDL3.so.0, got 0x55663e764840 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libtier0.so, got 0x55663e6361c0 +Visibility enabled. +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libfilesystem_stdio.so, got 0x55663e765460 +USRLOCAL path not found! +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/liblocalize.so, got 0x55663e765db0 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/librendersystemempty.so, got 0x55663e7666f0 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libresourcesystem.so, got 0x55663e767040 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libschemasystem.so, got 0x55663e767570 +Trying to set dxlevel (111) which is higher than the card can support (110)! +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libmaterialsystem2.so, got 0x55663e767aa0 +--------------- +Path ID: File Path: +ADDONS "/home/ubuntu/games/cs2/game/csgo_addons/" +CONTENT "/home/ubuntu/games/cs2/content/csgo/" +CONTENT "/home/ubuntu/games/cs2/content/csgo_imported/" +CONTENT "/home/ubuntu/games/cs2/content/csgo_core/" +CONTENT "/home/ubuntu/games/cs2/content/core/" +CONTENTADDONS "/home/ubuntu/games/cs2/content/csgo_addons/" +CONTENTROOT "/home/ubuntu/games/cs2/content/" +DEFAULT_WRITE_PATH "/home/ubuntu/games/cs2/game/csgo/pak01.vpk" (vpk) /home/ubuntu/games/cs2/game/csgo/pak01.vpk +DEFAULT_WRITE_PATH "/home/ubuntu/games/cs2/game/csgo/" +EXECUTABLE_PATH "/home/ubuntu/games/cs2/game/bin/linuxsteamrt64/" +GAME "/home/ubuntu/games/cs2/game/csgo/pak01.vpk" (vpk) /home/ubuntu/games/cs2/game/csgo/pak01.vpk +GAME "/home/ubuntu/games/cs2/game/csgo_imported/pak01.vpk" (vpk) /home/ubuntu/games/cs2/game/csgo_imported/pak01.vpk +GAME "/home/ubuntu/games/cs2/game/csgo_core/pak01.vpk" (vpk) /home/ubuntu/games/cs2/game/csgo_core/pak01.vpk +GAME "/home/ubuntu/games/cs2/game/core/pak01.vpk" (vpk) /home/ubuntu/games/cs2/game/core/pak01.vpk +GAME "/home/ubuntu/games/cs2/game/csgo/shaders_vulkan.vpk" (vpk) /home/ubuntu/games/cs2/game/csgo/shaders_vulkan.vpk +GAME "/home/ubuntu/games/cs2/game/csgo_core/shaders_vulkan.vpk" (vpk) /home/ubuntu/games/cs2/game/csgo_core/shaders_vulkan.vpk +GAME "/home/ubuntu/games/cs2/game/core/shaders_vulkan.vpk" (vpk) /home/ubuntu/games/cs2/game/core/shaders_vulkan.vpk +GAME "/home/ubuntu/games/cs2/game/csgo/" +GAME "/home/ubuntu/games/cs2/game/csgo_imported/" +GAME "/home/ubuntu/games/cs2/game/csgo_core/" +GAME "/home/ubuntu/games/cs2/game/core/" +GAMEBIN "/home/ubuntu/games/cs2/game/csgo/bin/linuxsteamrt64/" +GAMEBIN "/home/ubuntu/games/cs2/game/csgo/bin/" +GAMEBIN "/home/ubuntu/games/cs2/game/csgo_imported/bin/linuxsteamrt64/" +GAMEBIN "/home/ubuntu/games/cs2/game/csgo_imported/bin/" +GAMEBIN "/home/ubuntu/games/cs2/game/csgo_core/bin/linuxsteamrt64/" +GAMEBIN "/home/ubuntu/games/cs2/game/csgo_core/bin/" +GAMEBIN "/home/ubuntu/games/cs2/game/core/bin/linuxsteamrt64/" +GAMEBIN "/home/ubuntu/games/cs2/game/core/bin/" +GAMEROOT "/home/ubuntu/games/cs2/game/" +MOD "/home/ubuntu/games/cs2/game/csgo/pak01.vpk" (vpk) /home/ubuntu/games/cs2/game/csgo/pak01.vpk +MOD "/home/ubuntu/games/cs2/game/csgo_imported/pak01.vpk" (vpk) /home/ubuntu/games/cs2/game/csgo_imported/pak01.vpk +MOD "/home/ubuntu/games/cs2/game/csgo_core/pak01.vpk" (vpk) /home/ubuntu/games/cs2/game/csgo_core/pak01.vpk +MOD "/home/ubuntu/games/cs2/game/csgo/" +MOD "/home/ubuntu/games/cs2/game/csgo_imported/" +MOD "/home/ubuntu/games/cs2/game/csgo_core/" +OFFICIAL_ADDONS "/home/ubuntu/games/cs2/game/csgo_community_addons/" +PLATFORM "/home/ubuntu/games/cs2/game/core/pak01.vpk" (vpk) /home/ubuntu/games/cs2/game/core/pak01.vpk +PLATFORM "/home/ubuntu/games/cs2/game/core/" +SHADER_SOURCE "/home/ubuntu/games/cs2/src/shaders/csgo/" +SHADER_SOURCE "/home/ubuntu/games/cs2/src/shaders/csgo_imported/" +SHADER_SOURCE "/home/ubuntu/games/cs2/src/shaders/csgo_core/" +SHADER_SOURCE "/home/ubuntu/games/cs2/src/shaders/core/" +SHADER_SOURCE "/home/ubuntu/games/cs2/src/shaders/csgo_community_addons/" +SHADER_SOURCE_MOD "/home/ubuntu/games/cs2/src/shaders/csgo/" +SHADER_SOURCE_ROOT "/home/ubuntu/games/cs2/src/shaders/" +command line arguments: +-dedicated -usercon -console +game_type 0 +game_mode 1 +ip 0.0.0.0 -port 27015 +map de_dust2 -maxplayers 10 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libmeshsystem.so, got 0x55663e7df020 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libworldrenderer.so, got 0x55663e7f1570 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libpulse_system.so, got 0x55663e803ef0 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libvscript.so, got 0x55663e817df0 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libnetworksystem.so, got 0x55663e82a340 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libanimationsystem.so, got 0x55663e83e9a0 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libvphysics2.so, got 0x55663e8548c0 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libsoundsystem.so, got 0x55663e867a70 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libscenesystem.so, got 0x55663e87e1d0 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libv8system.so, got 0x55663e8940f0 +Network System Initialized +MOD desires lightbiner GPU but is unsupported by HW (SupportsCompute=0 CubeMapArrays=0) +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libserver_valve.so, got (nil) + failed to dlopen /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libserver_valve.so error=/home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libserver_valve.so: cannot open shared object file: No such file or directory + failed to dlopen "/home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libserver_valve.so" error=/home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libserver_valve.so: cannot open shared object file: No such file or directory +Loaded libserver_valve.so, got (nil) + failed to dlopen libserver_valve.so error=libserver_valve.so: cannot open shared object file: No such file or directory + failed to dlopen "libserver_valve.so" error=libserver_valve.so: cannot open shared object file: No such file or directory +Loaded /home/ubuntu/games/cs2/game/csgo/bin/linuxsteamrt64/libserver.so, got 0x55663e8b5f90 +Physics Console Communications is not initialized +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libengine2.so, got 0x55663e656fa0 +Loaded /home/ubuntu/games/cs2/game/csgo/bin/linuxsteamrt64/libhost.so, got 0x55663e8e6bb0 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libscenefilecache.so, got 0x55663e8fa180 +Loaded /home/ubuntu/games/cs2/game/bin/linuxsteamrt64/libparticles.so, got 0x55663e90c2c0 +Loaded /home/ubuntu/games/cs2/game/csgo/bin/linuxsteamrt64/libmatchmaking.so, got 0x55663e91f470 +No .vcds loaded or no scenes/scenes.vrman +GameTypes: missing mapgroupsSP entry for game type/mode (custom/custom). +GameTypes: missing mapgroupsSP entry for game type/mode (cooperative/cooperative). +GameTypes: missing mapgroupsSP entry for game type/mode (cooperative/coopmission). +Event System loaded 93 events from file: vpk:/home/ubuntu/games/cs2/game/core/pak01.vpk:resource/core.gameevents. +Event System loaded 50 events from file: vpk:/home/ubuntu/games/cs2/game/csgo/pak01.vpk:resource/game.gameevents. +Event System loaded 147 events from file: vpk:/home/ubuntu/games/cs2/game/csgo/pak01.vpk:./resource/mod.gameevents. +CEntitySystem::BuildEntityNetworking (parallel build of server) took 252.438 msecs for 205 out of 286 classes +[STARTUP] {4.119} server module init ok +./cs2.sh: line 5: 612780 Segmentation fault (core dumped) FEXInterpreter ~/games/cs2/game/bin/linuxsteamrt64/cs2 -dedicated -usercon -console +game_type 0 +game_mode 1 +ip 0.0.0.0 -port 27015 +map de_dust2 -maxplayers "10" +``` + +**Expected behavior** +Server running without segmentation fault. + +**System information:** + - OS: Ubuntu 24.04.2 LTS + - CPU/SoC: Server Neoverse-N1 aarch64 + - RootFS used: Downloaded using this command: `curl --silent https://raw.githubusercontent.com/FEX-Emu/FEX/main/Scripts/InstallFEX.py --output /tmp/InstallFEX.py && python3 /tmp/InstallFEX.py && rm /tmp/InstallFEX.py` + - FEX version: (FEXGetConfig --version) FEX-2505 + - Thunks Enabled: I didn't enable it explicitly... + +**Additional context** + - Is this an x86 or x86-64 game: x86-64 + +I will be more than happy to provide additional data that could help fix the problem more quickly. diff --git a/results/scraper/fex/4569 b/results/scraper/fex/4569 new file mode 100644 index 000000000..0abd833ae --- /dev/null +++ b/results/scraper/fex/4569 @@ -0,0 +1,63 @@ +The x64 exe loses most of the stack information during runtime, while the ARM64EC exe with the same code runs normally +FEX Version: git head: https://github.com/FEX-Emu/FEX/commit/09e622d5a03d55e39ff81668ab08a6595ddc5c5b +Wine Version: Wine tag 10.5 + +Reproduction Steps: +1. run x64 exe on wine-arm64ec build get empty stack; +2. run arm64ec exe on the same wine get normal stack; + +the exe file: +[exe.zip](https://github.com/user-attachments/files/20153585/exe.zip) + +The relevant data information is as follows: +info of x64 exe: +input parameters when calling functions in the executable: +input of NdrClientCall2: 00000001400034C0 0000000140005078 00000070D568FF20 0000000000000001 0000007012345678 00000070D568FF50 +Register dump: +ARM64 EL0t Mode + Pc:0000004ff6da1788 Sp:00000070d568fdd0 Lr:0000004ff6dc661c Cpsr:00000000(----) + x0: 00000001400034c0 x1: 0000000140005078 x2: 00000070d568ff40 x3: 0000000000000001 x4: 00000070d568ff00 + x5: 0000000000000000 x6: 00000070d4bafff8 x7: 0000007fffa0f680 x8: 00000070d568fed8 x9: 0000004ff6da1784 + x10:0000007fec4057d0 x11:0000004ffd2ac7ec x12:00000000000000ff x13:0000000000000000 x14:0000000000000000 + x15:0000000000000018 ip0:00000000d63f0200 ip1:0000004ff6dc65f4 x18:0000000000000000 x19:0000000000000000 + x20:0000000000000000 x21:0000000000000000 x22:0000000000000000 x23:0000000000000000 x24:0000000000000000 + x25:0000004ff6dd2800 x26:0000000000000000 x27:0000004ff6d40000 x28:0000000000000000 Fp:00000070d568fed0 +Stack dump: +0x000070d568fdd0: 00000070d568fed0 0000004ff6dc661c +0x000070d568fde0: 0000000000000000 0000000000000000 +0x000070d568fdf0: 0000000000000000 0000000000000000 +0x000070d568fe00: 0000000000000000 0000000000000000 +0x000070d568fe10: 0000000000000000 0000000000000000 +0x000070d568fe20: 0000000000000000 0000000000000000 +0x000070d568fe30: 0000000000000000 0000000000000000 +0x000070d568fe40: 0000000000000000 0000000000000000 +0x000070d568fe50: 0000000000000000 0000000000000000 +0x000070d568fe60: 0000000000000000 0000000000000000 +0x000070d568fe70: 0000000000000000 0000000000000000 +0x000070d568fe80: 0000000000000000 0000000000000000 + +info of arm64ec exe: +input parameters when calling functions in the executable: +input of NdrClientCall2: 00000001400073A0 000000014000A068 0000007257D4FF10 0000004F00000001 0000004F12345678 0000007257D4FF40 +Register dump: +ARM64 EL0t Mode + Pc:0000004ff6da1788 Sp:0000007257d4fe90 Lr:00000001400019c0 Cpsr:40000000(-Z--) + x0: 00000001400073a0 x1: 000000014000a068 x2: 0000007257d4ff30 x3: 0000000000000001 x4: 0000007257d4fef0 + x5: 0000000000000010 x6: 0000007257d4f2e0 x7: 0000000000000104 x8: 0000007257d4ff40 x9: 0000ccccfffcef76 + x10:0000000140003068 x11:0000004ff6da1784 x12:00000001000ffa68 x13:0000000000000000 x14:0000000000000000 + x15:0000000000000000 ip0:ccccfffcef76e95d ip1:ccccfffcef760000 x18:0000000000000000 x19:0000004ff6d40000 + x20:0000004ff6dd2800 x21:0000000140007000 x22:000000014000a000 x23:0000000000000000 x24:0000000000000000 + x25:0000000012345678 x26:0000000000000000 x27:0000000000000000 x28:0000000000000000 Fp:0000007257d4ff50 +Stack dump: +0x00007257d4fe90: 0000007257d4ff50 00000001400019c0 +0x00007257d4fea0: 0000007257d4ff50 0000000140001984 +0x00007257d4feb0: 0000004ff6d40000 0000004ff6dd2800 +0x00007257d4fec0: 0000000140007000 0000000000000000 +0x00007257d4fed0: 0000000000000000 00000001400073a0 +0x00007257d4fee0: 000000014000a068 0000007257d4ff10 +0x00007257d4fef0: 0000000012345678 0000007257d4ff40 +0x00007257d4ff00: 0000007257d4ff40 0000000140002620 +0x00007257d4ff10: 00000074e89ed170 00000001deadbeef +0x00007257d4ff20: 00000074e89ed170 00000074e89eff90 +0x00007257d4ff30: 00000074e89ed170 00000001deadbeef +0x00007257d4ff40: 0000000000000000 ffff84263ef41bad diff --git a/results/scraper/fex/4577 b/results/scraper/fex/4577 new file mode 100644 index 000000000..971b53933 --- /dev/null +++ b/results/scraper/fex/4577 @@ -0,0 +1,15 @@ +Upgrade clang-format to something other than 16 +Debian and Ubuntu in their infinite wisdom struck down clang-16 while keeping the other versions from 14 onwards. We just so happened to be using that version of clang for clang-format. + +``` +$ apt-cache search clang-format +clang-format-20 - Tool to format C/C++/Obj-C code +clang-format - Tool to format C/C++/Obj-C code +clang-format-14 - Tool to format C/C++/Obj-C code +clang-format-15 - Tool to format C/C++/Obj-C code +clang-format-17 - Tool to format C/C++/Obj-C code +clang-format-18 - Tool to format C/C++/Obj-C code +clang-format-19 - Tool to format C/C++/Obj-C code +``` + +We should upgrade to clang-format-18. \ No newline at end of file diff --git a/results/scraper/fex/4579 b/results/scraper/fex/4579 new file mode 100644 index 000000000..15e374f30 --- /dev/null +++ b/results/scraper/fex/4579 @@ -0,0 +1,2 @@ +Windows: Investigate potential mapping races +#4576 probably affects windows too, will need to use the pre/post arg \ No newline at end of file diff --git a/results/scraper/fex/4582 b/results/scraper/fex/4582 new file mode 100644 index 000000000..c01215793 --- /dev/null +++ b/results/scraper/fex/4582 @@ -0,0 +1,5 @@ +Divinity Original Sin II crashes in SupportTool.exe +https://store.steampowered.com/app/435150/Divinity_Original_Sin_2__Definitive_Edition/ +This game is seemingly crashing inside of coreclr inside of `ExecutionManager::getNextJumpStub` but it may be state corruption, hard to tell. + +This game might have worked at one point, so this might be a regression, but I don't quite remember. \ No newline at end of file diff --git a/results/scraper/fex/4588 b/results/scraper/fex/4588 new file mode 100644 index 000000000..5eeaca366 --- /dev/null +++ b/results/scraper/fex/4588 @@ -0,0 +1,2 @@ +FEXConfig doesn't expose 32-bit folders for library forwarding +These use separate config entries, but FEXConfig only sets the 64-bit ones. \ No newline at end of file diff --git a/results/scraper/fex/4589 b/results/scraper/fex/4589 new file mode 100644 index 000000000..0f7ac43ae --- /dev/null +++ b/results/scraper/fex/4589 @@ -0,0 +1,4 @@ +pusha/popa family generates incorrect code +Noticed in https://github.com/FEX-Emu/FEX/pull/4585 that these family of instructions are moving the SP to a temporary register and doing push/pop operations on the temporary and then moving the SP set to the end. + +If an async signal landed in the middle of that instruction then Linux async signal handling would corrupt the guest stack since it assumes correct guest SP at all times. \ No newline at end of file diff --git a/results/scraper/fex/46 b/results/scraper/fex/46 new file mode 100644 index 000000000..4ad29e774 --- /dev/null +++ b/results/scraper/fex/46 @@ -0,0 +1,10 @@ +Investigate available jits +javascript/wasm side +- [ ] v8 +- [ ] Mozilla + +.net side +- [ ] dotnetcore +- [ ] mono + +Others? diff --git a/results/scraper/fex/4626 b/results/scraper/fex/4626 new file mode 100644 index 000000000..7226d7d49 --- /dev/null +++ b/results/scraper/fex/4626 @@ -0,0 +1,2 @@ +[Question] How is the performance compared to Box64? +I'm wondering which one is faster for running game servers like cs2. \ No newline at end of file diff --git a/results/scraper/fex/4630 b/results/scraper/fex/4630 new file mode 100644 index 000000000..357d82910 --- /dev/null +++ b/results/scraper/fex/4630 @@ -0,0 +1,6 @@ +Library Forwarding: Find a more reliable way to deal with wl_interface globals +libQt6WaylandClient.so ships its own set of `wl_interface`s, which interferes with our code at: https://github.com/FEX-Emu/FEX/blob/a5fad89e57127e91ca3f6b7d6b020e65f7d7fb5f/ThunkLibs/libwayland-client/Guest.cpp#L10-L27 + +This can be reproduced simply by starting [Cutter](https://cutter.re/) in FEX, which will hang during startup. Using `WAYLAND_DEBUG=1`, it will print the error `interface '(null)' has no event 0`. + +A reliable workaround is to set `LD_PRELOAD=libwayland-client.so`. \ No newline at end of file diff --git a/results/scraper/fex/4639 b/results/scraper/fex/4639 new file mode 100644 index 000000000..5e52d26ff --- /dev/null +++ b/results/scraper/fex/4639 @@ -0,0 +1,14 @@ +X1E: Steam: Break when enabling thunks +Enabling any thunk breaks Steam on Ubuntu 25.04 running on X1E + + +```sh +pressure-vessel-wrap[17113]: Internal error: /usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json is not in /usr/lib/pressure-vessel/overrides/share/vulkan/explicit_layer.d +pressure-vessel-wrap[17113]: Internal error: /home/azkali/.local/share/vulkan/implicit_layer.d/steamfossilize_i386.json is not in /usr/lib/pressure-vessel/overrides/share/vulkan/implicit_layer.d +pressure-vessel-wrap[17113]: Internal error: /home/azkali/.local/share/vulkan/implicit_layer.d/steamfossilize_x86_64.json is not in /usr/lib/pressure-vessel/overrides/share/vulkan/implicit_layer.d +pressure-vessel-wrap[17113]: Internal error: /home/azkali/.local/share/vulkan/implicit_layer.d/steamoverlay_i386.json is not in /usr/lib/pressure-vessel/overrides/share/vulkan/implicit_layer.d +pressure-vessel-wrap[17113]: Internal error: /home/azkali/.local/share/vulkan/implicit_layer.d/steamoverlay_x86_64.json is not in /usr/lib/pressure-vessel/overrides/share/vulkan/implicit_layer.d +pressure-vessel-wrap[17113]: Internal error: /usr/share/vulkan/implicit_layer.d/VkLayer_MESA_device_select.json is not in /usr/lib/pressure-vessel/overrides/share/vulkan/implicit_layer.d +``` + +Without any thunk set, it works \ No newline at end of file diff --git a/results/scraper/fex/4645 b/results/scraper/fex/4645 new file mode 100644 index 000000000..5ecefb63d --- /dev/null +++ b/results/scraper/fex/4645 @@ -0,0 +1,61 @@ +32-Bit X11 OpenGL thunking incompatibilities mega-issue +I have concerns about thunks being enabled by default (especially 32-bit), neobrain wanted receipts, so here they are. + +DE used: i3wm. This is important as xwayland and other DEs will behave differently. + +Goal: Find which 32-bit games break when thunks are enabled. + +- Anything DXVK obviously doesn't matter since X11 Vulkan 32-bit thunking isn't a thing. But some retesting landed. +- Most games crash, some hang. Nothing really interesting from initial glance. + - Works: + - [Linux][GL] Grim Fandango Remastered + - [Linux][GL] Battleblock Theater + - [Linux][GL] Osmos + - [Linux][GL] Hotline Miami + - [Linux][GL] Full Throttle Remastered + - [Linux][GL] Pajama Sam's Lost and Found + - [Linux][GL] Cave Story+ + - [Linux][GL] Dungeons of Dredmor + - [Proton][DXVK] Sonic Mania + - [Proton][DXVK] Danganronpa 2: Goodbye Despair + - [Proton][DXVK-Native] Left 4 Dead + - [64-bit][Linux][DXVK-Native] Counter-strike Source + - [64-bit][Linux][DXVK-Native] Team Fortress 2 + - One of the few Source engine games that are 64-bit. + - Doesn't: + - [Proton][GL] Peggle Deluxe + - [Proton][GL] Gish + - [Proton][GL] Crayon Physics Deluxe + - [Proton][GL] Fieldrunners + - [Proton][GL] Plants vs. Zombies: Game of the Year + - [Proton][DXVK] Bejeweled 3 + - Even though this game uses DXVK, does something with GL. + - [Proton][GL] RAGE + - This one actually fails because thunks break Mesa's ability to find EXE names. + - [Linux][GL] Black Mesa + - [Linux][GL] Counter-Strike GoldSrc + - [Linux][GL] Day of Defeat + - [Linux][GL] Half-Life GoldSrc + - [Linux][GL] Half-Life 2 + - [Linux][GL] Half-Life: Source + - [Linux][GL] Half-Life: Blue Shift + - [Linux][GL] Half-Life: Opposing Force + - [Linux][GL] Portal + - [Linux][GL] Portal 2 + - [Linux][GL] Ricochet + - [Linux][GL] Team Fortress Classic + - [Linux][GL] Psychonauts + - [Linux][GL] Garry's Mod + - [Linux][GL] Left 4 Dead 2 + - [Linux][GL] Borderlands 2 + - [Linux][GL] Bioshock Infinite + - [Linux][GL] Saints Row 2 + - [Linux][GL] Saints Row: Gat out of Hell + - [Linux][GL] SOMA + - [Linux][GL] Massive Chalice + - [Linux][GL] Braid + - [Linux][GL] Brutal Legend + - [Linux][GL] Spec Ops: The Line + - [Linux][GL] Amnesia: The Dark Descent + - [Linux][GL] Dream Pinball 3D + - [Linux][GL] Costume Quest diff --git a/results/scraper/fex/4652 b/results/scraper/fex/4652 new file mode 100644 index 000000000..81da63163 --- /dev/null +++ b/results/scraper/fex/4652 @@ -0,0 +1,43 @@ +Steam: Fails to launch (2507 regression, possibly incorrect optimization) +**What Game** +Steam (the store itself) + +**Describe the bug** +Fails to launch on asahi post de4becc26e0c22a71b6615b3a2f35050e82fded0 + +**To Reproduce** +Launch steam + +**Expected behavior** +The app launches + +**System information:** + - OS: Linux 6.14 + - CPU/SoC: Apple M1 Pro + - Video driver version: Mesa 25.1.0-r100 + - RootFS used: Gentoo Asahi Rootfs + - FEX version: FEX-2507, bisected to de4becc26e0c22a71b6615b3a2f35050e82fded0 + - Thunks Enabled: No + +**Additional context** + - Is this an x86 or x86-64 game: Both + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: N/A + +Add any other context about the problem here. + +Optimization performed by commit de4becc26e0c22a71b6615b3a2f35050e82fded0 appears to be incorrect: +It transforms +``` +"mov w20, w6", +"udiv x22, x0, x20", +"udiv x22, x0, x20", +``` +into +``` +"udiv x20, x0, x6", +"mov w4, w20", +``` +Which is equivalent to transforming `(a // (b % 2**32)) % 2**32 into (a // b) % 2**32`, which is false for example with `a=2 b=1+2**32`. + +Reverting the relevant commit fixes the issue. \ No newline at end of file diff --git a/results/scraper/fex/466 b/results/scraper/fex/466 new file mode 100644 index 000000000..214446f54 --- /dev/null +++ b/results/scraper/fex/466 @@ -0,0 +1,5 @@ +Support SSE4.1 +Minit uses it unconditionally. + +https://steamdb.info/app/609490/ +https://store.steampowered.com/app/609490/Minit/ \ No newline at end of file diff --git a/results/scraper/fex/467 b/results/scraper/fex/467 new file mode 100644 index 000000000..a5fc302d4 --- /dev/null +++ b/results/scraper/fex/467 @@ -0,0 +1,3 @@ +Simple config program +Barebones configuration program that allows one to configure the global config. +FEXConfig \ No newline at end of file diff --git a/results/scraper/fex/4675 b/results/scraper/fex/4675 new file mode 100644 index 000000000..71c9f6f16 --- /dev/null +++ b/results/scraper/fex/4675 @@ -0,0 +1,35 @@ +Teardown: ground tile under player gets culled from view +**What Game** +[Teardown](https://store.steampowered.com/app/1167630) + +**Describe the bug** +The square tile of ground the player is very close to (either standing on or the next one over), when viewed from some angles, does not render. Instead, the map below is visible (see videos), probably because of a math error that makes the tile count as very far away instead of very close by(?) + +This happens with **both** OpenGL and VKD3D, **and** it feels like a very coarse massive-tile kind of culling that I would expect to happen on the CPU, so I think it's more likely to be an issue with FEX than with Mesa, but I could be wrong. If anyone could test on non-Qualcomm GPUs, that would quickly prove or disprove my hypothesis :) + +**To Reproduce** +Steps to reproduce the behavior: +1. Start playing, it's immediately obvious + +**Expected behavior** +The ground being solid :) + +**Screenshots and Video** + +https://github.com/user-attachments/assets/fe741c7b-c912-4d74-b4ab-bf5899a287b1 + +https://github.com/user-attachments/assets/59905b45-f7aa-45ea-9a32-a797e7a36828 + +**System information:** + - OS: postmarketOS edge + - CPU/SoC: Snapdragon X Elite (x1e80100) + - Video driver version: Mesa git (25.1-branchpoint-4169-g92d433c) + - RootFS used: none :p (not even nix this time, something else, coming soon hehe) + - FEX version: FEX-2507 + - Thunks Enabled: No + +**Additional context** + - Is this an x86 or x86-64 game: x86-64 + - Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested + - Is this a Vulkan game: Yes and No + - If Yes, What is your Vulkan driver: turnip \ No newline at end of file diff --git a/results/scraper/fex/468 b/results/scraper/fex/468 new file mode 100644 index 000000000..26647e5ff --- /dev/null +++ b/results/scraper/fex/468 @@ -0,0 +1,15 @@ +FEX Bash +Wrapper bash program that allows FEX to capture bash scripts and redirect programs that do architecture checking. +Good example is GOG scripts that check for 32bit or 64bit and will fall back to 32bit since the architecture isn't x86_64 + +First step would probably be a script that wraps the bash script and sets up environment variables so something like uname falls down a FEX loader path +`fexbash GOG/7\ Billion\ Humans/start.sh` + +Next step would probably be a bash shell that gives a terminal shell where you can execute commands in a pseudo-emulated environment +``` +$ uname -m +aarch64 +$ fexshell +$ uname -m +x86_64 +``` \ No newline at end of file diff --git a/results/scraper/fex/4686 b/results/scraper/fex/4686 new file mode 100644 index 000000000..de888c210 --- /dev/null +++ b/results/scraper/fex/4686 @@ -0,0 +1,23 @@ +libwow64fex crash in jemalloc with large number of cores +libwow64fex on Wine crashes early on startup trying to write to a null file descriptor. That's caused by jemalloc trying to print `jemalloc>: Reducing narenas to limit (4094)` to stderr, which is presumably not initialized yet. + +That's probably because the arena calculation depends on the number of cpus, and this specific machine has 128 cores. It works fine on other machines with fewer cores. + +``` +0024:Call ntdll.strlen(7ffffe1fe350 "<jemalloc>: Reducing narenas to limit (4094)\n") ret=6ffffacdae18 +0024:Ret ntdll.strlen() retval=0000002d ret=6ffffacdae18 +0024:Call ntdll.RtlAcquireSRWLockExclusive(6ffffae4dbc0) ret=6ffffac9b5f4 +0024:Ret ntdll.RtlAcquireSRWLockExclusive() retval=6ffffae4dbc0 ret=6ffffac9b5f4 +0024:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=00006FFFFAC7E4DC +0024:trace:seh:dispatch_exception info[0]=0000000000000000 +0024:trace:seh:dispatch_exception info[1]=0000000000000010 +0024:trace:seh:dispatch_exception pc=00006ffffac7e4dc sp=00007ffffe1fe320 lr=00006ffffac7e4d4 fp=00007ffffe1ff690 +0024:trace:seh:dispatch_exception x0=00006ffffae4dbc0 x1=000000007ffc3404 x2=0000000000000052 x3=0000000000000001 +0024:trace:seh:dispatch_exception x4=0000000000000000 x5=00006ffffae4dbc0 x6=00006ffffac9b5f4 x7=0000000000000000 +0024:trace:seh:dispatch_exception x8=0000000000000000 x9=0000000060000000 x10=00007ffffe0ffcd0 x11=000000000000000a +0024:trace:seh:dispatch_exception x12=0000000000000048 x13=0000000000000000 x14=000000007ffc3451 x15=000000000000745c +0024:trace:seh:dispatch_exception x16=00007ffffe1fde10 x17=00006fffffa1b2c0 x18=000000007ffc0000 x19=000000000000002d +0024:trace:seh:dispatch_exception x20=00007ffffe1fe350 x21=0000000000000002 x22=00006ffffae4dbc0 x23=00006ffffae56000 +0024:trace:seh:dispatch_exception x24=00006ffffae56130 x25=00006ffffafc0000 x26=0000000000000030 x27=00007ffffe1ff850 +0024:trace:seh:dispatch_exception x28=000000000000007e cpsr=00001000 fpcr=00000000 fpsr=00000000 +``` diff --git a/results/scraper/fex/469 b/results/scraper/fex/469 new file mode 100644 index 000000000..d2936fc8b --- /dev/null +++ b/results/scraper/fex/469 @@ -0,0 +1,2 @@ +Allow Independent 32bit and 64bit rootfs paths +Can be useful depending on the circumstances. \ No newline at end of file diff --git a/results/scraper/fex/47 b/results/scraper/fex/47 new file mode 100644 index 000000000..92c8ea300 --- /dev/null +++ b/results/scraper/fex/47 @@ -0,0 +1,2 @@ +Implement IR Caching and Code Caching +Including caching for dynamic objects loaded \ No newline at end of file diff --git a/results/scraper/fex/477 b/results/scraper/fex/477 new file mode 100644 index 000000000..bcb41e776 --- /dev/null +++ b/results/scraper/fex/477 @@ -0,0 +1,85 @@ +Perf: <<ByteMark to 80% native>> Roadmap +# <<ByteMark to 80% native>> Roadmap + +Bytemark performance tracking: [Graph](https://docs.google.com/spreadsheets/d/e/2PACX-1vStbhGzR4w1Zqw57iMgsTm04EV0JkjA3LsS4aQXrY2ZlXwYBjVkZK6bz5atigxzwBkUk9GOfy64-8XS/pubchart?oid=1396476138&format=interactive) + +Based on the systemic profiling/perf work of the past 2 weeks, + `skmp/optihacks-1`, `skmp/optihacks-2` and `skmp/optihacks-3` + some analysis on ByteMark today I think the following is a good game plan for this goal: + +## Cleanup changes in `skmp/optihacks-3`. +- Compat limits: Optional PF disable, Optional InvalidateFlags for ABI crossings. + +## Lightweight guest branching & dispatch +Targets: Switch tables, indirect functions +### Reduce Lookup overhead +Current paged lookup + alias check + validation check is clearly not optimal. + +I suggest a 2-layer approach, with the first layer being a cache and the second a tree / paged tree. + +For the first layer, I'd use 24 bit lookup + alias check + lazy allocate LUT. + +#### Basic Structure +``` +struct { uint64_t guest; uint64_t host } entry_t; +entry_t *LUT; // possibly mmap + segfault backed for lazy allocation +``` + +#### Indirect Code Lookup +``` +_fast_loopup: +and x0, pc , ( (1 << 24) -1) +add entry_ptr, lookup_base + x0* 16 +ldp x0,x1, [entry_ptr] +cmp x0, pc +b.ne _full_lookup<pc_reg> // we need a detwiddling table here +br x1 +``` + +### Block linking +Blocks that are statically mapped should link to each other. I propose to use indirect branches to implement this, with the branch vectors being allocated near the block. + +#### Basic Structure +``` +struct BlockInfo { .... uintptr_t* StaticBranchHostPtr; uint64_t StaticBranchGuest; } + +// during code emition do a _non_mapped_handler: .dq addr <default_handler> and initialize StaticBranchHostPtr +``` +#### Block ending for blocks that exit with CALL_DIRECT, JUMP_DIRECT +``` +ldr x0 =_non_mapped_handler +blr x0 // BLR is important here, doesn't return +``` +#### Block ending for blocks that exit with RET, CALL_INDIRECT, JUMP_INDIRECT +``` +and x0, pc , ( (1 << 24) -1) +add entry_ptr, lookup_base + x0* 16 +ldp x0,x1, [entry_ptr] +cmp x0, pc +b.ne _full_lookup<pc_reg> // we need a detwiddling table here +br x1 +``` + +#### PC-recovery +In order to reduce overhead, no validation is done on the DIRECT forms - so the default case needs to handle that. We can recover the block from the ret address (that's why BLR is needed). Then we can link the block + +#### Block link metadata +We need to keep lists of which blocks link to witch for block invalidations + +## Static Register Allocation +Allocate 8 or 16 GPRs statically, do RA for SSA values on the rest regs. Make sure to support "lifetime sharing" when an SSA should share the host register with a guest reg as long as it is valid, and generate movs as needed. + +### Multiblock +#### Multiple Entry Points +Right only the main entry point is exported to the cache. Big blocks that call other blocks should export secondary entry points at the expected return points, to avoid multiple partial code compilations of the same function + +#### PHI nodes (possibly not needed to meet goals) +We need the RA to support PHI nodes + +#### MB-DCLSE (possibly not needed to meet goals) +We need Dead Context Load Store Elim to generate PHI nodes + +### Address important pathological code gen +Shuffles are one example, and there might be a few more important cases for ByteMARK + +--- + +@Sonicadvance1 @phire thoughts? \ No newline at end of file diff --git a/results/scraper/fex/48 b/results/scraper/fex/48 new file mode 100644 index 000000000..b38520d9c --- /dev/null +++ b/results/scraper/fex/48 @@ -0,0 +1,3 @@ +Investigate small programs that could be benchmarks +Specint, specperf, POVRAY....? +We also need ARMv8.2 hardware that isn't quirk to ensure this. \ No newline at end of file diff --git a/results/scraper/fex/49 b/results/scraper/fex/49 new file mode 100644 index 000000000..84efb4c4d --- /dev/null +++ b/results/scraper/fex/49 @@ -0,0 +1,5 @@ +Parse ELF interpreter correctly so we don't have to pass in dynamic linker +Right now ELFLoader is not pulling in the dynamic linker from the ELF. +This is requiring us to launch apps through the linker directly, which clang absolutely hates. +Pass it through ELFLoader so we no longer need to do this. +Saves us headaches, will be needed when we hook through binutils. \ No newline at end of file diff --git a/results/scraper/fex/494 b/results/scraper/fex/494 new file mode 100644 index 000000000..d276b85e2 --- /dev/null +++ b/results/scraper/fex/494 @@ -0,0 +1,29 @@ +Buildbot LoadCI integration +LoadCI integration is a time consuming process. List of steps we need to support. + + +**Step 1** +- [ ] Switch CI system over to buildbot + - [ ] Show buildbot steps in in Github view + - [ ] Block merge when buildbot not ran (When not authenticated) + - [ ] Allow Admin CI running via comment + - [ ] Show results of LoadCI in comment + - [ ] Block merging when performance has degraded + - [ ] Allow manual override (Only authenticated users) +- [ ] Github event notification + - [ ] Authentication check with buildbot group + - [ ] LoadCI message stating changed performance on + - [ ] Only merge LoadCI results to Postgres on main master merge + +**Step 2** +- [ ] Discord integration + - [ ] Show failures against main branch in bots channel + - [ ] Kick off PR build directly from bots channel (Only authenticated users) + +**Step 3** +- [ ] Load balancing / Job splitting + - [ ] Every builder must build its own instance of FEX + - [ ] Create runner families that should closely match performance to one another + - [ ] Split LoadCI jobs to runner families + +https://docs.google.com/document/d/1Km9ZFdSx932_z61kbV9DVkdJAg-OUqx-37KrsJmpDI8/edit# \ No newline at end of file diff --git a/results/scraper/fex/495 b/results/scraper/fex/495 new file mode 100644 index 000000000..5e7435ccc --- /dev/null +++ b/results/scraper/fex/495 @@ -0,0 +1,36 @@ +Offline Debugging & Performance Analysis tools +Following up some discussions with @Sonicadvance1 + +## Exposed via FEXLoader +### IR dumping to folder +Rationale: We need the data for offline analysis +- Add `--dump-ir=path/to/folder`? +- Save like `<block guest addr>_<block hash>` to avoid collisions +- Should dump both "IR" and "Mixed IR/Host Code" + +### Per-block support for multiblock in perf symbols +Rationale: Superblocks can have 10s of blocks, it is important to attribute runtime to the hot ones +- Export each sub-block as `<superblock main entry>-<basicblock entry>`? +- Add it as a command line option, `--perf-metadata=none|basic|detailed`? + +### `GuestOp` IR op +Rationale: We need to better track Guest - IR - Host relationships to spot optimization opportunities +- Stores Guest Address, Guest opcode and Guest disassembly, allows us to better AB between Guest and IR +- Exposed via `--ir-debug-metadata`? + +## Add Offline IR compiler +Rationale: Allow us to iterate over a specific block/superblock without having to relaunch the guest application +- Should Accept IR as dumped by FEXLoader +- Should be able to show "Mixed IR/Host Code" +- Should be able to calculate basic metrics like "Instruction Blowup" and "Code Size Blowup" + +## Tighter perf integration / Perf Explorer +Rationale: We tooling to help us find optimization opportunities and slowdowns, and to also test the "simulated" effects of WIP optimizations +- Show perf data scaled by blowup or other metrics +- Be able to take a perf trace + ir dump and calculate metrics like "average executed code per trace", and also break down by category like "memory", "vector" etc + +--- + +I'd use these as command line utilities in an offline fashion myself. + +@Sonicadvance1 @phire, thoughts? \ No newline at end of file diff --git a/results/scraper/fex/498 b/results/scraper/fex/498 new file mode 100644 index 000000000..9467bec16 --- /dev/null +++ b/results/scraper/fex/498 @@ -0,0 +1,5 @@ +Static TLS setup is incorrect +This is wrong for both 64bit and 32bit. + +Uncommon to hit since it only affects static apps that use TLS. +Most apps get launched through glibc's dynamic loader which sets up dynamic apps TLS region. \ No newline at end of file diff --git a/results/scraper/fex/510 b/results/scraper/fex/510 new file mode 100644 index 000000000..d527e0384 --- /dev/null +++ b/results/scraper/fex/510 @@ -0,0 +1,5 @@ +Stop duplicating ASM dispatcher per thread +Currently the ASM dispatcher is duplicated per thread, which is a waste of a page or two of memory per thread. +Additionally it's burning a few cachelines of CPU cache. + +Clean this up \ No newline at end of file diff --git a/results/scraper/fex/514 b/results/scraper/fex/514 new file mode 100644 index 000000000..dca4a8ccc --- /dev/null +++ b/results/scraper/fex/514 @@ -0,0 +1,2 @@ +glibc SSSE3 strcmp returning invalid results on 32bit +Haven't fully investigated why this fails, it's a huge function. diff --git a/results/scraper/fex/515 b/results/scraper/fex/515 new file mode 100644 index 000000000..9f2b99c26 --- /dev/null +++ b/results/scraper/fex/515 @@ -0,0 +1,14 @@ +Allocator hooking for 32bit and 64bit +https://man7.org/linux/man-pages/man3/malloc_hook.3.html +We need to hook these functions and replace them in the frontend so our application is handling all memory allocations ourselves. + +There are 3 sub tasks here + + - [] For 64bit these effectively just pass through. + - [] For 32bit we need to steal the upper 64bits virtual memory region so 32bit mmap and ioctl will be forced to allocate in the lower 32bit region + - This allows us to do stronger investigations to see if we require the Linux kernel to have new syscalls + - [] Pass allocation routines throughout our core so thunked libraries in 32bit applications hit our malloc and force allocations in to the lower 32bits + +I would like the first two tasks to be completed in two weeks time, so roughly around December 3rd. Since I know RA is currently higher priority for @phire. This is one of their secondary tasks. + +Something like this was also asked for Wine integration, which also wants some hooking for thread allocation which is a different task. \ No newline at end of file diff --git a/results/scraper/fex/518 b/results/scraper/fex/518 new file mode 100644 index 000000000..174898b65 --- /dev/null +++ b/results/scraper/fex/518 @@ -0,0 +1,3 @@ +Support guest long jump from signal handler +This trips up our signal handling in ways that makes it hard to determine if we can clear code caches. +Not sure exactly how to capture this case. Needs some thinking. \ No newline at end of file diff --git a/results/scraper/fex/519 b/results/scraper/fex/519 new file mode 100644 index 000000000..c26b0c111 --- /dev/null +++ b/results/scraper/fex/519 @@ -0,0 +1,3 @@ +SonicUtils merge in to FEXCore +Remove the unused bits (VM mainly) and merge the rest in to FEXCore. +This will stop forcing Stefan to revert the change. \ No newline at end of file diff --git a/results/scraper/fex/521 b/results/scraper/fex/521 new file mode 100644 index 000000000..be918f1d4 --- /dev/null +++ b/results/scraper/fex/521 @@ -0,0 +1,4 @@ +Move Syscall handling to the frontend +This is necessary to clean up Wine versus Linux integration. +There will be some cross-communication where we make some choices in the backend depending on current ABI. +Which is necessary to not take a performance hit. \ No newline at end of file diff --git a/results/scraper/fex/522 b/results/scraper/fex/522 new file mode 100644 index 000000000..974560654 --- /dev/null +++ b/results/scraper/fex/522 @@ -0,0 +1,2 @@ +Get Steam running with 32bit support +Clean up the hacky branch and push. \ No newline at end of file diff --git a/results/scraper/fex/523 b/results/scraper/fex/523 new file mode 100644 index 000000000..7fab8b226 --- /dev/null +++ b/results/scraper/fex/523 @@ -0,0 +1,2 @@ +Allow passing in a 32bit specific rootfs +Necessary to not have 64bit and 32bit constantly overlap. \ No newline at end of file diff --git a/results/scraper/fex/526 b/results/scraper/fex/526 new file mode 100644 index 000000000..8b8c681a5 --- /dev/null +++ b/results/scraper/fex/526 @@ -0,0 +1,6 @@ +IRListView copies should support allocating from slab allocator +Currently each IRListView copy calls in to malloc to create the copy. +glibc seems to be hitting the worst case where it is and then calling mprotect for every IR copy. This is significantly more overhead than necessary and is dirtying strace output quite heavily. + +We should allow passing in a slab allocator to this instead to reduce the number of syscalls we are doing here. +Keep the malloc path in the case we want an independent copy still. \ No newline at end of file diff --git a/results/scraper/fex/527 b/results/scraper/fex/527 new file mode 100644 index 000000000..2c806a7ad --- /dev/null +++ b/results/scraper/fex/527 @@ -0,0 +1,3 @@ +Geekbench crashes in Image Inpainting test +``` Running Image Inpainting +geekbench_x86_64: src/geekbench/inpaint/inpaint_util.h:67: float scaled_patch_distance_sse(const Image<float> &, const Image<float> &, int, int, int, int) [patch_size = 7, channels = 3]: Assertion `x1 - patch_radius >= 0 && x1 + patch_radius < img1.width() && y1 - patch_radius >= 0 && y1 + patch_radius < img1.height() && x2 - patch_radius >= 0 && x2 + patch_radius < img2.width() && y2 - patch_radius >= 0 && y2 + patch_radius < img2.height()' failed.``` \ No newline at end of file diff --git a/results/scraper/fex/560 b/results/scraper/fex/560 new file mode 100644 index 000000000..8c9d09843 --- /dev/null +++ b/results/scraper/fex/560 @@ -0,0 +1,6 @@ +Check that single float/double SSE opcodes have correct access sizes on the tables/codegen +Follow up from #543 + +We need to +- Check that the x86 table correctly mark the sizes for all SS and SD opcodes +- Validate that OpDisp doesn't generate needless inserts \ No newline at end of file diff --git a/results/scraper/fex/561 b/results/scraper/fex/561 new file mode 100644 index 000000000..d86e8ac02 --- /dev/null +++ b/results/scraper/fex/561 @@ -0,0 +1,4 @@ +Make sure that tests that pass don't crash +Follow up from #559 + +Sometimes when tests crash with sigsegv they get treated as if they passed. We need to investigate why and make sure it doesn't happen to any other tests \ No newline at end of file diff --git a/results/scraper/fex/564 b/results/scraper/fex/564 new file mode 100644 index 000000000..223f5ad55 --- /dev/null +++ b/results/scraper/fex/564 @@ -0,0 +1,7 @@ +Check if we are a binfmt_misc application, change execve behaviour +If we were executed through binfmt_misc, then we should change behaviour of execve. +Passing arguments to FEXLoader through execve has a chance of breaking from my testing of /bin/sh based applications on steam. + +- Stop passing arguments to FEXLoader from execve + - Requires better configuration +- If we are the binfmt_misc interpreter and the application getting called in execve would call us directly, remove FEXLoader from the launch arguments. \ No newline at end of file diff --git a/results/scraper/fex/565 b/results/scraper/fex/565 new file mode 100644 index 000000000..57f71e6eb --- /dev/null +++ b/results/scraper/fex/565 @@ -0,0 +1,2 @@ +fix bash script executing +I have some WIP code that finds a bug in our bash script execution, need to dig it up and fix it. \ No newline at end of file diff --git a/results/scraper/fex/567 b/results/scraper/fex/567 new file mode 100644 index 000000000..324d928ba --- /dev/null +++ b/results/scraper/fex/567 @@ -0,0 +1,4 @@ +Have FEXCore fetch its configuration from the overlay configuration +Stated in the description of #566. +Currently the frontend sets up the configuration layers, but it is falling down the legacy codepath of the frontend still being required to pass the context its configuration. +The context should be able to fetch its configuration from the overlay configuration itself. \ No newline at end of file diff --git a/results/scraper/fex/570 b/results/scraper/fex/570 new file mode 100644 index 000000000..18aa2a430 --- /dev/null +++ b/results/scraper/fex/570 @@ -0,0 +1,23 @@ +/bin/sh execution failing - Breaks Evoland Legendary Edition launching +### Preface +https://store.steampowered.com/app/1020470/Evoland_Legendary_Edition/ +https://steamdb.info/app/1020470/ +This game's launch command is `linux/run.sh` + +This is fairly innocuous until you inspect what is inside that file + +``` +LD_PRELOAD= LD_LIBRARY_PATH=linux ./linux/hl linux/detect.hl +LD_PRELOAD= LD_LIBRARY_PATH=linux ./linux/hl sdlboot.dat +``` +It has no interpreter line in the header which means if you try launching the game with `FEXLoader %command%` in the launch arguments of Steam. FEXLoader will try parsing the file, realize it isn't an ELF or `#!` shebang interpreter file and crash out. + +This happens to work on Linux because steam launches all games with `sh -c %command%`. + +Looks like we are going to have to switch over to `FEXInterpreter /bin/sh -c %command%` instead now. With /bin/sh coming from our rootfs overlay. + +### Problem +Somewhere along the line we managed to break launching applications from /bin/sh, or behaviour has changed enough on my host system that this isn't working anymore. +Easy enough to reproduce by running /bin/sh under FEX and trying to ls a directory. +The process will fork and spin on some ioctls and signals around switching process foreground/background switching. +Good chance that signals are causing issues here. \ No newline at end of file diff --git a/results/scraper/fex/571 b/results/scraper/fex/571 new file mode 100644 index 000000000..b2a5d0717 --- /dev/null +++ b/results/scraper/fex/571 @@ -0,0 +1,9 @@ +Execve fails due to /proc/self/exe usage +We determine if we are in "Interpreter" mode by checking application executable name to be FEXInterpreter. +Interpreter mode is necessary since we need to ignore arguments passed in since it breaks execution in a lot of cases. + +`/proc/self/exe` sees through our softlink to FEXLoader which means we lose the determination that we are the interpreter. + +We have two options. +- Disable all argument loading and just use FEXConfig for option setting. +- Do a hardlink install to FEXLoader \ No newline at end of file diff --git a/results/scraper/fex/572 b/results/scraper/fex/572 new file mode 100644 index 000000000..3a0761d3b --- /dev/null +++ b/results/scraper/fex/572 @@ -0,0 +1,7 @@ +Allow environment variable to pass in application config location +Either allow passing a folder to search for the application config in, thus allowing a single folder to service multiple config files. +And/Or allow passing an environment variable with a single config file to use regardless of app config. + +eg: +`FEX_APP_CONFIG_LOCATION=$(PWD)/AppConfigs/` +`FEX_APP_CONFIG=/tmp/Config.json` \ No newline at end of file diff --git a/results/scraper/fex/573 b/results/scraper/fex/573 new file mode 100644 index 000000000..2d019b6e5 --- /dev/null +++ b/results/scraper/fex/573 @@ -0,0 +1,4 @@ +Allow passing config to FEXConfig to initially load +Allow passing in one argument that is a config file. +If file exists, load it, if file doesn't exist then load default config and set current filename to it. +Allows quick config loading and saving \ No newline at end of file diff --git a/results/scraper/fex/574 b/results/scraper/fex/574 new file mode 100644 index 000000000..6576ef55e --- /dev/null +++ b/results/scraper/fex/574 @@ -0,0 +1,5 @@ +Add support for SSE 4.2 +Only something to worry about once our performance is good enough for newer AAA titles. + +Apparently Doom Eternal uses the CRC instruction specifically. +The string compare ops likely won't map very well to anything in AArch64... \ No newline at end of file diff --git a/results/scraper/fex/575 b/results/scraper/fex/575 new file mode 100644 index 000000000..4dfb60a20 --- /dev/null +++ b/results/scraper/fex/575 @@ -0,0 +1,3 @@ +jecxz and friends instructions broken on 32bit +Valgrind tests pick this up. +Causes infinite loop diff --git a/results/scraper/fex/580 b/results/scraper/fex/580 new file mode 100644 index 000000000..536e3cc75 --- /dev/null +++ b/results/scraper/fex/580 @@ -0,0 +1,8 @@ +IR: Explicit Size Metadata +Follow up from #524 + +In order to more effectively do read-aliasing we need to specify in the IR +- Which bits are used for each op +- Whenever the opcode produces a zext'd result +- Differences between operation size and destination size + diff --git a/results/scraper/fex/581 b/results/scraper/fex/581 new file mode 100644 index 000000000..b1bed7a2b --- /dev/null +++ b/results/scraper/fex/581 @@ -0,0 +1,18 @@ +Support AVX list +Find a list of games that use AVX unconditionally to gauge priority for implementing. +We need both good enough performance and a list of games that use AVX before thinking about implementing. +It'll have a minor perf hit to implement since all of our context switching ends up being twice the size. + +Games that use AVX unconditionally (at time of writing or that we've discovered): +- Cyberpunk 2077 (Unconditional usage removed in 1.05) +- Metro Exodus (And enhanced edition) +- Sonic Frontiers +- Uncharted: Legacy of Thieves Collection +- Returnal +- Death Stranding +- Forspoken +- Star citizen +- Sea of Stars +- Starfield + +https://wiki.fex-emu.com/index.php/Category:AVX_CPU_Feature \ No newline at end of file diff --git a/results/scraper/fex/585 b/results/scraper/fex/585 new file mode 100644 index 000000000..84dfcd464 --- /dev/null +++ b/results/scraper/fex/585 @@ -0,0 +1,14 @@ +Optimize Long divide and long remainder on AArch64 JIT +We currently call out to a helper routine for LDIV, LUDIV, LREM, and LUREM IR ops. +This is because AArch64 doesn't have native support for a 128bit value being divided by a 64bit divisor like x86 does. + +### Step 1 +Good first step would probably be to check if the top 64bits of the dividend are zero for unsigned divide and only branch to helper if they aren't. Doing fast divide in that case. +Then for signed, check to ensure that the top bits are all the same as the top bit of bit 63 of the lower source (sbfe + cmp) and do the fast one there. +Same for the remainder bits. + +### Step A +After that would probably be to inline the full long divide/remainder when it is actually needed. + +### Step I +We should also have an optimization pass that downgrades long divide/remainder to regular divide and remainder when the top bits are discarded, or the incoming bits were zext/sext before the op. \ No newline at end of file diff --git a/results/scraper/fex/586 b/results/scraper/fex/586 new file mode 100644 index 000000000..1bcde0671 --- /dev/null +++ b/results/scraper/fex/586 @@ -0,0 +1,6 @@ +Add optimization pass that changes integer divide to shifts +Loads of integer divides are dividing by powers of two. + +First task is to investigate how often the divisor can be const propagated. +Second task is to see what percentage of those divisors are power of twos +Third task is to convert the division from a divide to a shift. Either by using SBFE or BFE for the sign handling depending on udiv or sdiv. \ No newline at end of file diff --git a/results/scraper/fex/587 b/results/scraper/fex/587 new file mode 100644 index 000000000..40c82f035 --- /dev/null +++ b/results/scraper/fex/587 @@ -0,0 +1,3 @@ +32bit TLS broken +Currently on new thread the the TLS segment that is trying to get loaded in to the GDT/LDT is completely broken. +Causes TLS to break for 32bit guests. \ No newline at end of file diff --git a/results/scraper/fex/59 b/results/scraper/fex/59 new file mode 100644 index 000000000..0deba9488 --- /dev/null +++ b/results/scraper/fex/59 @@ -0,0 +1,2 @@ +Remove SARX usage +High priority, red alert \ No newline at end of file diff --git a/results/scraper/fex/590 b/results/scraper/fex/590 new file mode 100644 index 000000000..3d15b3c10 --- /dev/null +++ b/results/scraper/fex/590 @@ -0,0 +1,3 @@ +epoll_event struct differen't between x86 and aarch64 +Make sure to translate these to the new host correctly. +Currently we just pass them through. \ No newline at end of file diff --git a/results/scraper/fex/591 b/results/scraper/fex/591 new file mode 100644 index 000000000..ffa10dfc9 --- /dev/null +++ b/results/scraper/fex/591 @@ -0,0 +1,3 @@ +Capture x86-64 applications jumping to 32bit syscalls +x86-64 applications can still call in to the 32bit x86 syscall interface with `int 0x80` +Capture this case. \ No newline at end of file diff --git a/results/scraper/fex/592 b/results/scraper/fex/592 new file mode 100644 index 000000000..e8b5227fc --- /dev/null +++ b/results/scraper/fex/592 @@ -0,0 +1,30 @@ +ConstProp RemoveUselessMasking pass breaks 8-bit test/jnz +In an application's use of zlib 1.2.3 (inflate_fast) compiled with MSVC, the following basic block is observed: + +```asm +mov r11d, [r9+rax*4] +mov eax, r11d +movzx edx, r11b +shr eax, 8 +movzx ecx, al +shr ebx, cl +sub r10d, ecx +test r11b, r11b +jnz short loc_141284962 +``` + +However, the following IR is generated for the test/jcc: + +``` + %ssa45(GPR0) i64 = Select %ssa11(GPR0) i32, %ssa42(Invalid4294967295), %ssa43(Invalid4294967295), %ssa44(Invalid4294967295), EQ, #0x8 + (%ssa46 i0) StoreFlag %ssa45(GPR0) i64, #0x6 + %ssa47(GPR1) i64 = Constant #0x0 + (%ssa48 i0) StoreFlag %ssa47(GPR1) i64, #0x0 + %ssa49(GPR1) i64 = Constant #0x0 + (%ssa50 i0) StoreFlag %ssa49(GPR1) i64, #0xb + (%ssa51 i0) InlineConstant #0x0 + (%ssa52 i0) CondJump %ssa45(GPR0) i64, %ssa51(Invalid4294967295), %ssa3(Invalid4294967295), %ssa4(Invalid4294967295), EQ, #0x8 + (%ssa53 i0) EndBlock %ssa2(Invalid4294967295) +``` + +`r11d` at this time contained a value `0x00410400`, which leads to the jump being incorrectly taken, for a 32-bit compare-to-zero is used as a jump condition. \ No newline at end of file diff --git a/results/scraper/fex/594 b/results/scraper/fex/594 new file mode 100644 index 000000000..65dd4bc58 --- /dev/null +++ b/results/scraper/fex/594 @@ -0,0 +1,3 @@ +Correctly fix ConstProp/RemoveUselessMasking +Depends on #580 + diff --git a/results/scraper/fex/596 b/results/scraper/fex/596 new file mode 100644 index 000000000..2a24a8590 --- /dev/null +++ b/results/scraper/fex/596 @@ -0,0 +1,8 @@ +Prefetchw not fully implemented +Currently: +Only partial table implementation in `X86Tables/SecondaryGroupTables.cpp` +Table in `OpcodeDispatcher.cpp` doesn't even have the instruction. + +Should be implemented as a nop, maybe discuss implementing as a real prefetch in the future. + +CPUID also currently claims support for prefetchw \ No newline at end of file diff --git a/results/scraper/fex/598 b/results/scraper/fex/598 new file mode 100644 index 000000000..33eef52a3 --- /dev/null +++ b/results/scraper/fex/598 @@ -0,0 +1,2 @@ +x87 ALU ops don't set x87 flags +Causes the qemu TCG tests to infinite loop. \ No newline at end of file diff --git a/results/scraper/fex/599 b/results/scraper/fex/599 new file mode 100644 index 000000000..6bf273c6c --- /dev/null +++ b/results/scraper/fex/599 @@ -0,0 +1,2 @@ +Emulated CPU core option, let it query host cores +If set to 0 then have FEX query the host for the number of cores and pass it directly to the guest. \ No newline at end of file diff --git a/results/scraper/fex/600 b/results/scraper/fex/600 new file mode 100644 index 000000000..0992b451e --- /dev/null +++ b/results/scraper/fex/600 @@ -0,0 +1,4 @@ +Pull uname nodename from host system. +Currently we just populate it with "FEXCore" on both 32bit and 64bit LInux. +This causes Steam to state "FEXCore is available for streaming". +Let's nab this from the host uname instead. \ No newline at end of file diff --git a/results/scraper/fex/602 b/results/scraper/fex/602 new file mode 100644 index 000000000..f69c9bcbf --- /dev/null +++ b/results/scraper/fex/602 @@ -0,0 +1,6 @@ +DEQP unit tests runner doesn't run correctly under FEX +When trying to run the unit test runner it will just try running some WGL tests and stop early. +https://android.googlesource.com/platform/external/deqp/ +Follow build steps in external/openglcts/README.md for building +then run the output `cts-runner` or `glcts` program +Not sure what is wrong here but these would be nice to get running. \ No newline at end of file diff --git a/results/scraper/fex/603 b/results/scraper/fex/603 new file mode 100644 index 000000000..9089c47dc --- /dev/null +++ b/results/scraper/fex/603 @@ -0,0 +1,345 @@ +Multiblock will fail on certain conditional AVX/FMA usage (BreakOnFrontendFailure is forced to true) +In the following function (as seen in modern versions of MSVC CRT), there is a conditional check for AVX (dword_18042FD20, 'FMA supported'). + +```asm +.text:00000001803077A0 sub rsp, 58h ; lm2k data: +.text:00000001803077A4 movdqa [rsp+58h+var_38], xmm6 +.text:00000001803077AA cmp cs:dword_18042FD20, 0 +.text:00000001803077B1 jnz loc_180307AA0 +.text:00000001803077B7 movapd xmm3, xmm0 +.text:00000001803077BB movapd xmm4, xmm0 +.text:00000001803077BF psrlq xmm3, 34h ; '4' +.text:00000001803077C4 movq rax, xmm0 +.text:00000001803077C9 psubq xmm3, cs:xmmword_1803A3970 +.text:00000001803077D1 movapd xmm5, xmm0 +.text:00000001803077D5 andpd xmm5, cs:xmmword_1803A3940 +.text:00000001803077DD comisd xmm5, qword ptr cs:xmmword_1803A3940 +.text:00000001803077E5 jz loc_180307A70 +.text:00000001803077EB movapd xmm2, xmm0 +.text:00000001803077EF cvtdq2pd xmm6, xmm3 +.text:00000001803077F3 xorpd xmm5, xmm5 +.text:00000001803077F7 comisd xmm0, xmm5 +.text:00000001803077FB jbe loc_180307A30 +.text:0000000180307801 pand xmm2, cs:xmmword_1803A3990 +.text:0000000180307809 subsd xmm4, qword ptr cs:xmmword_1803A3A20 +.text:0000000180307811 comisd xmm6, cs:qword_1803A3AB0 +.text:0000000180307819 jz loc_1803079F7 +.text:000000018030781F +.text:000000018030781F loc_18030781F: ; CODE XREF: log10+289?j +.text:000000018030781F andpd xmm4, cs:xmmword_1803A3B10 +.text:0000000180307827 mov r9, rax +.text:000000018030782A and rax, qword ptr cs:xmmword_1803A39A0 +.text:0000000180307831 and r9, qword ptr cs:xmmword_1803A39B0 +.text:0000000180307838 shl r9, 1 +.text:000000018030783B add rax, r9 +.text:000000018030783E movq xmm1, rax +.text:0000000180307843 comisd xmm4, cs:qword_1803A3AD0 +.text:000000018030784B jb loc_180307930 +.text:0000000180307851 shr rax, 2Ch +.text:0000000180307855 por xmm2, cs:xmmword_1803A3A30 +.text:000000018030785D por xmm1, cs:xmmword_1803A3A30 +.text:0000000180307865 lea r9, dbl_1803A03E0 +.text:000000018030786C subsd xmm1, xmm2 +.text:0000000180307870 mulsd xmm1, qword ptr [r9+rax*8] +.text:0000000180307876 movapd xmm2, xmm1 +.text:000000018030787A movapd xmm0, xmm1 +.text:000000018030787E lea r9, dbl_1803A3B80 +.text:0000000180307885 movsd xmm3, cs:qword_1803A3AA0 +.text:000000018030788D movsd xmm1, cs:qword_1803A3A70 +.text:0000000180307895 mulsd xmm3, xmm2 +.text:0000000180307899 mulsd xmm1, xmm2 +.text:000000018030789D mulsd xmm0, xmm2 +.text:00000001803078A1 movapd xmm4, xmm0 +.text:00000001803078A5 addsd xmm3, cs:qword_1803A3A90 +.text:00000001803078AD addsd xmm1, cs:qword_1803A3A60 +.text:00000001803078B5 mulsd xmm4, xmm0 +.text:00000001803078B9 mulsd xmm3, xmm2 +.text:00000001803078BD mulsd xmm1, xmm0 +.text:00000001803078C1 addsd xmm3, cs:qword_1803A3A80 +.text:00000001803078C9 addsd xmm1, xmm2 +.text:00000001803078CD mulsd xmm3, xmm4 +.text:00000001803078D1 addsd xmm1, xmm3 +.text:00000001803078D5 movsd xmm5, cs:qword_1803A3A00 +.text:00000001803078DD mulsd xmm1, cs:qword_1803A39C0 +.text:00000001803078E5 mulsd xmm5, xmm6 +.text:00000001803078E9 subsd xmm5, xmm1 +.text:00000001803078ED movsd xmm0, qword ptr [r9+rax*8] +.text:00000001803078F3 lea rdx, dbl_1803A4390 +.text:00000001803078FA movsd xmm2, qword ptr [rdx+rax*8] +.text:00000001803078FF movsd xmm4, cs:qword_1803A39F0 +.text:0000000180307907 mulsd xmm4, xmm6 +.text:000000018030790B addsd xmm0, xmm4 +.text:000000018030790F addsd xmm2, xmm5 +.text:0000000180307913 addsd xmm0, xmm2 +.text:0000000180307917 movdqa xmm6, [rsp+58h+var_38] +.text:000000018030791D add rsp, 58h +.text:0000000180307921 retn +.text:0000000180307921 ; --------------------------------------------------------------------------- +.text:0000000180307922 align 10h +.text:0000000180307930 +.text:0000000180307930 loc_180307930: ; CODE XREF: log10+AB?j +.text:0000000180307930 movsd xmm2, cs:qword_1803A3A10 ; ------ INTEZER ------ +.text:0000000180307930 ; Common - INTEZER.Common +.text:0000000180307930 ; --------------------- +.text:0000000180307938 subsd xmm0, qword ptr cs:xmmword_1803A3A20 +.text:0000000180307940 addsd xmm2, xmm0 +.text:0000000180307944 movapd xmm1, xmm0 +.text:0000000180307948 divsd xmm1, xmm2 +.text:000000018030794C movsd xmm4, cs:qword_1803A3B30 +.text:0000000180307954 movsd xmm5, cs:qword_1803A3B50 +.text:000000018030795C movapd xmm6, xmm0 +.text:0000000180307960 mulsd xmm6, xmm1 +.text:0000000180307964 addsd xmm1, xmm1 +.text:0000000180307968 movapd xmm2, xmm1 +.text:000000018030796C mulsd xmm2, xmm1 +.text:0000000180307970 mulsd xmm4, xmm2 +.text:0000000180307974 mulsd xmm5, xmm2 +.text:0000000180307978 addsd xmm4, cs:qword_1803A3B20 +.text:0000000180307980 addsd xmm5, cs:qword_1803A3B40 +.text:0000000180307988 mulsd xmm2, xmm1 +.text:000000018030798C mulsd xmm4, xmm2 +.text:0000000180307990 mulsd xmm2, xmm2 +.text:0000000180307994 mulsd xmm2, xmm1 +.text:0000000180307998 mulsd xmm5, xmm2 +.text:000000018030799C movsd xmm2, cs:qword_1803A39E0 +.text:00000001803079A4 addsd xmm4, xmm5 +.text:00000001803079A8 subsd xmm4, xmm6 +.text:00000001803079AC movsd xmm6, cs:qword_1803A39D0 +.text:00000001803079B4 movapd xmm3, xmm0 +.text:00000001803079B8 pand xmm3, cs:xmmword_1803A3B60 +.text:00000001803079C0 subsd xmm0, xmm3 +.text:00000001803079C4 addsd xmm4, xmm0 +.text:00000001803079C8 movapd xmm0, xmm3 +.text:00000001803079CC movapd xmm1, xmm4 +.text:00000001803079D0 mulsd xmm4, xmm2 +.text:00000001803079D4 mulsd xmm0, xmm2 +.text:00000001803079D8 mulsd xmm1, xmm6 +.text:00000001803079DC mulsd xmm3, xmm6 +.text:00000001803079E0 addsd xmm0, xmm4 +.text:00000001803079E4 addsd xmm0, xmm1 +.text:00000001803079E8 addsd xmm0, xmm3 +.text:00000001803079EC movdqa xmm6, [rsp+58h+var_38] +.text:00000001803079F2 add rsp, 58h +.text:00000001803079F6 retn +.text:00000001803079F7 ; --------------------------------------------------------------------------- +.text:00000001803079F7 +.text:00000001803079F7 loc_1803079F7: ; CODE XREF: log10+79?j +.text:00000001803079F7 por xmm2, cs:xmmword_1803A3A20 +.text:00000001803079FF subsd xmm2, qword ptr cs:xmmword_1803A3A20 +.text:0000000180307A07 movsd xmm5, xmm2 +.text:0000000180307A0B pand xmm2, cs:xmmword_1803A3990 +.text:0000000180307A13 movq rax, xmm2 +.text:0000000180307A18 psrlq xmm5, 34h ; '4' +.text:0000000180307A1D psubd xmm5, cs:xmmword_1803A3AC0 +.text:0000000180307A25 cvtdq2pd xmm6, xmm5 +.text:0000000180307A29 jmp loc_18030781F +.text:0000000180307A29 ; --------------------------------------------------------------------------- +.text:0000000180307A2E align 10h +.text:0000000180307A30 +.text:0000000180307A30 loc_180307A30: ; CODE XREF: log10+5B?j +.text:0000000180307A30 jnz short loc_180307A50 +.text:0000000180307A32 movsd xmm1, cs:qword_1803A3930 +.text:0000000180307A3A mov r8d, cs:dword_1803A3B70 +.text:0000000180307A41 call _log10_special +.text:0000000180307A46 jmp short loc_180307A90 +.text:0000000180307A46 ; --------------------------------------------------------------------------- +.text:0000000180307A48 align 10h +.text:0000000180307A50 +.text:0000000180307A50 loc_180307A50: ; CODE XREF: log10:loc_180307A30?j +.text:0000000180307A50 ; log10+2E0?j +.text:0000000180307A50 movsd xmm1, cs:qword_1803A3950 +.text:0000000180307A58 mov r8d, cs:dword_1803A3B74 +.text:0000000180307A5F call _log10_special +.text:0000000180307A64 jmp short loc_180307A90 +.text:0000000180307A64 ; --------------------------------------------------------------------------- +.text:0000000180307A66 align 10h +.text:0000000180307A70 +.text:0000000180307A70 loc_180307A70: ; CODE XREF: log10+45?j +.text:0000000180307A70 cmp rax, qword ptr cs:xmmword_1803A3940 +.text:0000000180307A77 jz short loc_180307A90 +.text:0000000180307A79 cmp rax, cs:qword_1803A3930 +.text:0000000180307A80 jz short loc_180307A50 +.text:0000000180307A82 or rax, cs:qword_1803A3960 +.text:0000000180307A89 movq xmm0, rax +.text:0000000180307A8E xchg ax, ax +.text:0000000180307A90 +.text:0000000180307A90 loc_180307A90: ; CODE XREF: log10+2A6?j +.text:0000000180307A90 ; log10+2C4?j ... +.text:0000000180307A90 movdqa xmm6, [rsp+58h+var_38] +.text:0000000180307A96 add rsp, 58h +.text:0000000180307A9A retn +.text:0000000180307A9A ; --------------------------------------------------------------------------- +.text:0000000180307A9B align 20h +.text:0000000180307AA0 +.text:0000000180307AA0 loc_180307AA0: ; CODE XREF: log10+11?j +.text:0000000180307AA0 xor rax, rax +.text:0000000180307AA3 vpsrlq xmm3, xmm0, 34h ; '4' +.text:0000000180307AA8 vmovq rax, xmm0 +.text:0000000180307AAD vpsubq xmm3, xmm3, cs:xmmword_1803A3970 +.text:0000000180307AB5 vcvtdq2pd xmm6, xmm3 +.text:0000000180307AB9 vpand xmm5, xmm0, cs:xmmword_1803A3940 +.text:0000000180307AC1 vcomisd xmm5, qword ptr cs:xmmword_1803A3940 +.text:0000000180307AC9 jz loc_180307D10 +.text:0000000180307ACF vpxor xmm5, xmm5, xmm5 +.text:0000000180307AD3 vcomisd xmm0, xmm5 +.text:0000000180307AD7 jbe loc_180307CC0 +.text:0000000180307ADD vpand xmm2, xmm0, cs:xmmword_1803A3990 ; ------ INTEZER ------ +.text:0000000180307ADD ; Common - INTEZER.Common +.text:0000000180307ADD ; --------------------- +.text:0000000180307AE5 vsubsd xmm4, xmm0, qword ptr cs:xmmword_1803A3A20 +.text:0000000180307AED vcomisd xmm6, cs:qword_1803A3AB0 +.text:0000000180307AF5 jz loc_180307C89 +.text:0000000180307AFB +.text:0000000180307AFB loc_180307AFB: ; CODE XREF: log10+516?j +.text:0000000180307AFB vpand xmm1, xmm0, cs:xmmword_1803A39A0 ; ------ INTEZER ------ +.text:0000000180307AFB ; Common - INTEZER.Common +.text:0000000180307AFB ; --------------------- +.text:0000000180307B03 vpand xmm3, xmm0, cs:xmmword_1803A39B0 +.text:0000000180307B0B vpsllq xmm3, xmm3, 1 +.text:0000000180307B10 vpaddq xmm1, xmm3, xmm1 +.text:0000000180307B14 vmovq rax, xmm1 +.text:0000000180307B19 vpand xmm4, xmm4, cs:xmmword_1803A3B10 +.text:0000000180307B21 vcomisd xmm4, cs:qword_1803A3AD0 +.text:0000000180307B29 jb loc_180307BE0 +.text:0000000180307B2F shr rax, 2Ch ; ------ INTEZER ------ +.text:0000000180307B2F ; Common - INTEZER.Common +.text:0000000180307B2F ; --------------------- +.text:0000000180307B33 vpor xmm2, xmm2, cs:xmmword_1803A3A30 +.text:0000000180307B3B vpor xmm1, xmm1, cs:xmmword_1803A3A30 +.text:0000000180307B43 lea r9, dbl_1803A03E0 +.text:0000000180307B4A vsubsd xmm1, xmm1, xmm2 +.text:0000000180307B4E vmulsd xmm1, xmm1, qword ptr [r9+rax*8] +.text:0000000180307B54 lea r9, dbl_1803A3B80 +.text:0000000180307B5B vmulsd xmm0, xmm1, xmm1 +.text:0000000180307B5F vmovsd xmm3, cs:qword_1803A3AA0 +.text:0000000180307B67 vmovsd xmm5, cs:qword_1803A3A70 +.text:0000000180307B6F vfmadd213sd xmm3, xmm1, cs:qword_1803A3A90 +.text:0000000180307B78 vfmadd213sd xmm5, xmm1, qword ptr cs:xmmword_1803A3A30 +.text:0000000180307B81 movsd xmm4, xmm0 +.text:0000000180307B85 vfmadd213sd xmm3, xmm1, cs:qword_1803A3A80 +.text:0000000180307B8E vmulsd xmm4, xmm0, xmm0 +.text:0000000180307B92 vfmadd231sd xmm1, xmm5, xmm0 +.text:0000000180307B97 vfmadd231sd xmm1, xmm3, xmm4 +.text:0000000180307B9C vmulsd xmm1, xmm1, cs:qword_1803A39C0 +.text:0000000180307BA4 vmovsd xmm5, cs:qword_1803A3A00 +.text:0000000180307BAC vfmsub213sd xmm5, xmm6, xmm1 +.text:0000000180307BB1 movsd xmm0, qword ptr [r9+rax*8] +.text:0000000180307BB7 lea rdx, dbl_1803A4390 +.text:0000000180307BBE movsd xmm2, qword ptr [rdx+rax*8] +.text:0000000180307BC3 vaddsd xmm2, xmm2, xmm5 +.text:0000000180307BC7 vfmadd231sd xmm0, xmm6, cs:qword_1803A39F0 +.text:0000000180307BD0 vaddsd xmm0, xmm0, xmm2 +.text:0000000180307BD4 vmovdqa xmm6, [rsp+58h+var_38] +.text:0000000180307BDA add rsp, 58h +.text:0000000180307BDE retn +.text:0000000180307BDE ; --------------------------------------------------------------------------- +.text:0000000180307BDF align 20h +.text:0000000180307BE0 +.text:0000000180307BE0 loc_180307BE0: ; CODE XREF: log10+389?j +.text:0000000180307BE0 vmovsd xmm2, cs:qword_1803A3A10 ; ------ INTEZER ------ +.text:0000000180307BE0 ; Common - INTEZER.Common +.text:0000000180307BE0 ; --------------------- +.text:0000000180307BE8 vsubsd xmm0, xmm0, qword ptr cs:xmmword_1803A3A20 +.text:0000000180307BF0 vaddsd xmm2, xmm2, xmm0 +.text:0000000180307BF4 vdivsd xmm1, xmm0, xmm2 +.text:0000000180307BF8 vmovsd xmm4, cs:qword_1803A3B30 +.text:0000000180307C00 vmovsd xmm5, cs:qword_1803A3B50 +.text:0000000180307C08 vmulsd xmm6, xmm0, xmm1 +.text:0000000180307C0C vaddsd xmm1, xmm1, xmm1 +.text:0000000180307C10 vmulsd xmm2, xmm1, xmm1 +.text:0000000180307C14 vfmadd213sd xmm4, xmm2, cs:qword_1803A3B20 +.text:0000000180307C1D vfmadd213sd xmm5, xmm2, cs:qword_1803A3B40 +.text:0000000180307C26 vmulsd xmm2, xmm2, xmm1 +.text:0000000180307C2A vmulsd xmm4, xmm4, xmm2 +.text:0000000180307C2E vmulsd xmm2, xmm2, xmm2 +.text:0000000180307C32 vmulsd xmm2, xmm2, xmm1 +.text:0000000180307C36 vmulsd xmm5, xmm5, xmm2 +.text:0000000180307C3A vaddsd xmm4, xmm4, xmm5 +.text:0000000180307C3E vsubsd xmm4, xmm4, xmm6 +.text:0000000180307C42 vpand xmm3, xmm0, cs:xmmword_1803A3B60 +.text:0000000180307C4A vsubsd xmm0, xmm0, xmm3 +.text:0000000180307C4E vaddsd xmm4, xmm4, xmm0 +.text:0000000180307C52 vmulsd xmm1, xmm4, cs:qword_1803A39D0 +.text:0000000180307C5A vmulsd xmm4, xmm4, cs:qword_1803A39E0 +.text:0000000180307C62 vmulsd xmm0, xmm3, cs:qword_1803A39E0 +.text:0000000180307C6A vmulsd xmm3, xmm3, cs:qword_1803A39D0 +.text:0000000180307C72 vaddsd xmm0, xmm0, xmm4 +.text:0000000180307C76 vaddsd xmm0, xmm0, xmm1 +.text:0000000180307C7A vaddsd xmm0, xmm0, xmm3 +.text:0000000180307C7E vmovdqa xmm6, [rsp+58h+var_38] +.text:0000000180307C84 add rsp, 58h +.text:0000000180307C88 retn +.text:0000000180307C89 ; --------------------------------------------------------------------------- +.text:0000000180307C89 +.text:0000000180307C89 loc_180307C89: ; CODE XREF: log10+355?j +.text:0000000180307C89 vpor xmm2, xmm2, cs:xmmword_1803A3A20 +.text:0000000180307C91 vsubsd xmm2, xmm2, qword ptr cs:xmmword_1803A3A20 +.text:0000000180307C99 vpsrlq xmm5, xmm2, 34h ; '4' +.text:0000000180307C9E vpand xmm2, xmm2, cs:xmmword_1803A3990 +.text:0000000180307CA6 vmovapd xmm0, xmm2 +.text:0000000180307CAA vpsubd xmm5, xmm5, cs:xmmword_1803A3AC0 +.text:0000000180307CB2 vcvtdq2pd xmm6, xmm5 +.text:0000000180307CB6 jmp loc_180307AFB +.text:0000000180307CB6 ; --------------------------------------------------------------------------- +.text:0000000180307CBB align 20h +.text:0000000180307CC0 +.text:0000000180307CC0 loc_180307CC0: ; CODE XREF: log10+337?j +.text:0000000180307CC0 jnz short loc_180307CF0 +.text:0000000180307CC2 vmovsd xmm1, cs:qword_1803A3930 +.text:0000000180307CCA mov r8d, cs:dword_1803A3B70 +.text:0000000180307CD1 call _log10_special +.text:0000000180307CD6 vmovdqa xmm6, [rsp+58h+var_38] +.text:0000000180307CDC add rsp, 58h +.text:0000000180307CE0 retn +.text:0000000180307CE0 ; --------------------------------------------------------------------------- +.text:0000000180307CE1 align 10h +.text:0000000180307CF0 +.text:0000000180307CF0 loc_180307CF0: ; CODE XREF: log10:loc_180307CC0?j +.text:0000000180307CF0 ; log10+580?j +.text:0000000180307CF0 vmovsd xmm1, cs:qword_1803A3950 +.text:0000000180307CF8 mov r8d, cs:dword_1803A3B74 +.text:0000000180307CFF call _log10_special +.text:0000000180307D04 vmovdqa xmm6, [rsp+58h+var_38] +.text:0000000180307D0A add rsp, 58h +.text:0000000180307D0E retn +.text:0000000180307D0E ; --------------------------------------------------------------------------- +.text:0000000180307D0F align 10h +.text:0000000180307D10 +.text:0000000180307D10 loc_180307D10: ; CODE XREF: log10+329?j +.text:0000000180307D10 cmp rax, qword ptr cs:xmmword_1803A3940 +.text:0000000180307D17 jz short loc_180307D40 +.text:0000000180307D19 cmp rax, cs:qword_1803A3930 +.text:0000000180307D20 jz short loc_180307CF0 +.text:0000000180307D22 or rax, cs:qword_1803A3960 +.text:0000000180307D29 movq xmm1, rax +.text:0000000180307D2E mov r8d, cs:dword_1803A3B78 +.text:0000000180307D35 call _log10_special +.text:0000000180307D3A jmp short loc_180307D40 +.text:0000000180307D3A ; --------------------------------------------------------------------------- +.text:0000000180307D3C align 20h +.text:0000000180307D40 +.text:0000000180307D40 loc_180307D40: ; CODE XREF: log10+577?j +.text:0000000180307D40 ; log10+59A?j +.text:0000000180307D40 vmovdqa xmm6, [rsp+58h+var_38] +.text:0000000180307D46 add rsp, 58h +.text:0000000180307D4A retn +.text:0000000180307D4A log10 endp +``` + +However, with multiblock + a 500 block size, the block at `loc_180307AA0` will still be compiled, and will hit an assertion on the `vcvtdq2pd` instruction (`C5 FA E6 F3`): + +```asm +.text:0000000180307AA0 loc_180307AA0: ; CODE XREF: log10+11?j +.text:0000000180307AA0 xor rax, rax +.text:0000000180307AA3 vpsrlq xmm3, xmm0, 34h ; '4' +.text:0000000180307AA8 vmovq rax, xmm0 +.text:0000000180307AAD vpsubq xmm3, xmm3, cs:xmmword_1803A3970 +.text:0000000180307AB5 vcvtdq2pd xmm6, xmm3 +.text:0000000180307AB9 vpand xmm5, xmm0, cs:xmmword_1803A3940 +.text:0000000180307AC1 vcomisd xmm5, qword ptr cs:xmmword_1803A3940 +.text:0000000180307AC9 jz loc_180307D10 +``` + +A number of other cases of a similar conditional check also failed on a similar unsupported/undecodable instruction. + +It seems that `Context::CompileCode` does allow interrupting multi-block handling in case of a decoding error, but with BreakOnFrontendFailure being enabled (which it is _always_ as it doesn't seem exposed to the configuration system) this'll lead to a fatal error instead. \ No newline at end of file diff --git a/results/scraper/fex/604 b/results/scraper/fex/604 new file mode 100644 index 000000000..d41d4ee1d --- /dev/null +++ b/results/scraper/fex/604 @@ -0,0 +1,2 @@ +Rename upstream branch to main +Make sure to not miss the scripts that use the old name. \ No newline at end of file diff --git a/results/scraper/fex/607 b/results/scraper/fex/607 new file mode 100644 index 000000000..6c93bb8a2 --- /dev/null +++ b/results/scraper/fex/607 @@ -0,0 +1 @@ +SRA: Recover FPRs on exception diff --git a/results/scraper/fex/608 b/results/scraper/fex/608 new file mode 100644 index 000000000..f0c7c6f15 --- /dev/null +++ b/results/scraper/fex/608 @@ -0,0 +1 @@ +SRA: Configurable SRA regs + disable SRA option diff --git a/results/scraper/fex/609 b/results/scraper/fex/609 new file mode 100644 index 000000000..613e48fcc --- /dev/null +++ b/results/scraper/fex/609 @@ -0,0 +1 @@ +SRA: Give back top 8 GPRS/FPRs to RA on x86-32 diff --git a/results/scraper/fex/610 b/results/scraper/fex/610 new file mode 100644 index 000000000..300e59c53 --- /dev/null +++ b/results/scraper/fex/610 @@ -0,0 +1 @@ +SRA: Re-enable block live range calculations diff --git a/results/scraper/fex/611 b/results/scraper/fex/611 new file mode 100644 index 000000000..3f48b9389 --- /dev/null +++ b/results/scraper/fex/611 @@ -0,0 +1 @@ +SRA: re-allocation when the regs don't hold context values diff --git a/results/scraper/fex/612 b/results/scraper/fex/612 new file mode 100644 index 000000000..1ae32da8f --- /dev/null +++ b/results/scraper/fex/612 @@ -0,0 +1 @@ +Dispatch: Embed the pointers to some context param diff --git a/results/scraper/fex/613 b/results/scraper/fex/613 new file mode 100644 index 000000000..99fff64ac --- /dev/null +++ b/results/scraper/fex/613 @@ -0,0 +1 @@ +Dispatch: Simplify dispatcher (Compile and such is shouldn't be in assembly) diff --git a/results/scraper/fex/614 b/results/scraper/fex/614 new file mode 100644 index 000000000..50a719d4c --- /dev/null +++ b/results/scraper/fex/614 @@ -0,0 +1 @@ +Dispatch: Do distributed dispatching diff --git a/results/scraper/fex/615 b/results/scraper/fex/615 new file mode 100644 index 000000000..f2e0aeffe --- /dev/null +++ b/results/scraper/fex/615 @@ -0,0 +1 @@ +Dispatch: Do block linking diff --git a/results/scraper/fex/616 b/results/scraper/fex/616 new file mode 100644 index 000000000..328cd3d76 --- /dev/null +++ b/results/scraper/fex/616 @@ -0,0 +1,2 @@ +Tests: Investigate importing gVisor syscall tests +See: https://github.com/google/gvisor/tree/master/test/syscalls/linux \ No newline at end of file diff --git a/results/scraper/fex/617 b/results/scraper/fex/617 new file mode 100644 index 000000000..26952a444 --- /dev/null +++ b/results/scraper/fex/617 @@ -0,0 +1,9 @@ +Tag a version so we can have one in uname. +This should be date version. +eg: +`FEX-<YY><MM>.<Rev>` +so `FEX-2101` +And then with rev `FEX-2101.1` + +This way we can expose it to uname. +I want to do this after 32bit stuff lands. \ No newline at end of file diff --git a/results/scraper/fex/620 b/results/scraper/fex/620 new file mode 100644 index 000000000..2c3a59a1f --- /dev/null +++ b/results/scraper/fex/620 @@ -0,0 +1,9 @@ +Investigate gvisor test failures +## Overview +Several gvisor tests fail, and those are largely real failures + +- [ ] Investigate failures +- [ ] Create tickets + +## Follow up +- [ ] Solve tickets \ No newline at end of file diff --git a/results/scraper/fex/630 b/results/scraper/fex/630 new file mode 100644 index 000000000..d1af19319 --- /dev/null +++ b/results/scraper/fex/630 @@ -0,0 +1,2 @@ +#619 Introduced more flakes +Fix it. \ No newline at end of file diff --git a/results/scraper/fex/633 b/results/scraper/fex/633 new file mode 100644 index 000000000..be96419c6 --- /dev/null +++ b/results/scraper/fex/633 @@ -0,0 +1,4 @@ +Create 32bit unit tests around 32bit mode negative offset jumps +Sext may not be working correctly. +Generate unit tests to ensure it keeps working. +Also generate additional unit tests to check operand size, address size changes? \ No newline at end of file diff --git a/results/scraper/fex/634 b/results/scraper/fex/634 new file mode 100644 index 000000000..c5d04fb87 --- /dev/null +++ b/results/scraper/fex/634 @@ -0,0 +1,3 @@ +Support 32bit x86 host code runner for CI +Linux allows us to create 32bit code segments. +This means that we could get a 32bit host code runner setup for our ASM tests. \ No newline at end of file diff --git a/results/scraper/fex/635 b/results/scraper/fex/635 new file mode 100644 index 000000000..515bd5aa3 --- /dev/null +++ b/results/scraper/fex/635 @@ -0,0 +1,3 @@ +Make ASM and IR tests track compiled file dependencies correctly +Custom targets `asm_tests`, 32bit_asm_tests`, and `ir_tests` don't currently have a dependency on their respective `{asm, 32bit_asm,ir}_files` target. +This means you can accidentally run the tests without the compile being as fresh as possible. \ No newline at end of file diff --git a/results/scraper/fex/636 b/results/scraper/fex/636 new file mode 100644 index 000000000..3d5907407 --- /dev/null +++ b/results/scraper/fex/636 @@ -0,0 +1,4 @@ +Need 16bit addressing mode unit tests +#626 needs some unit tests to go along with it. +Grab some instructions and use 16bit addressing to ensure they are generated correctly. +Probably good to test addressing mode + operand size override with all configurations. \ No newline at end of file diff --git a/results/scraper/fex/647 b/results/scraper/fex/647 new file mode 100644 index 000000000..d74053394 --- /dev/null +++ b/results/scraper/fex/647 @@ -0,0 +1,11 @@ +Geekbench fails to upload results +After testing (due to another bug, you currently need to test with `-T 1` geekbench fails to upload results to the server with: + +``` +Uploading results to the Geekbench Browser. This could take a minute or two +depending on the speed of your internet connection. + + unknown error (internal code 35) +``` + +Before exiting. \ No newline at end of file diff --git a/results/scraper/fex/648 b/results/scraper/fex/648 new file mode 100644 index 000000000..0f5939ad7 --- /dev/null +++ b/results/scraper/fex/648 @@ -0,0 +1,2 @@ +Add a option to make vector loadstores atomic +Yep. This is a thing on x86. \ No newline at end of file diff --git a/results/scraper/fex/649 b/results/scraper/fex/649 new file mode 100644 index 000000000..4940519e8 --- /dev/null +++ b/results/scraper/fex/649 @@ -0,0 +1,4 @@ +Dispatch: Store RIP on exits from the JIT abi +Follow up from #637 + +We need to store the RIP whenever it can't be implicitly recovered from PC \ No newline at end of file diff --git a/results/scraper/fex/650 b/results/scraper/fex/650 new file mode 100644 index 000000000..a62f344f4 --- /dev/null +++ b/results/scraper/fex/650 @@ -0,0 +1,2 @@ +Dispatch: Recover RIP on asynchronous signals +With #637 RIP is no longer synchronized per block-entry. This might affect signals. We should recover RIP by doing a reverse lookup on PC whenever we get a signal and we are inside the jit abi. Depends on #649 for completeness \ No newline at end of file diff --git a/results/scraper/fex/652 b/results/scraper/fex/652 new file mode 100644 index 000000000..c89c22f66 --- /dev/null +++ b/results/scraper/fex/652 @@ -0,0 +1,4 @@ +Add -O0 style optimization pass disable argument +Make sure this is in FEXConfig GUI. +Just make it -O0 from CLI. +Have it disable all optimization passes. \ No newline at end of file diff --git a/results/scraper/fex/654 b/results/scraper/fex/654 new file mode 100644 index 000000000..d9b8962d8 --- /dev/null +++ b/results/scraper/fex/654 @@ -0,0 +1,5 @@ +Steam slow to initialize due to interpreter +During steam initialization it spends about 70% of CPU time in the interpreter. This will be because of x87 fallback. +We need to isolate the hot blocks and force implement the ops necessary to get these running in the JITs. + +After initialization it looks to be sitting at anywhere from 5-15% interpreter time which is still a significant chunk of time. \ No newline at end of file diff --git a/results/scraper/fex/656 b/results/scraper/fex/656 new file mode 100644 index 000000000..9d8936ade --- /dev/null +++ b/results/scraper/fex/656 @@ -0,0 +1,3 @@ +Add host kernel check to FEXLoader +FEXLoader requires MAP_FIXED_NOREPLACE which was added in kernel 4.17. +WSL1 only emulates kernel 4.4 so it falls over. \ No newline at end of file diff --git a/results/scraper/fex/659 b/results/scraper/fex/659 new file mode 100644 index 000000000..41f0c79c3 --- /dev/null +++ b/results/scraper/fex/659 @@ -0,0 +1,2 @@ +OpDisp: Add more FPU cases in SelectCC +We currently handle only 0x2, 0x3, 0x6, 0x7, 0xA, 0xB, everything else is forced to do full flags calculation \ No newline at end of file diff --git a/results/scraper/fex/661 b/results/scraper/fex/661 new file mode 100644 index 000000000..cb1dd0546 --- /dev/null +++ b/results/scraper/fex/661 @@ -0,0 +1,2 @@ +Drop FEX describe tag in to CPUID +Have cmake add the describe tag to the generated header and use it. \ No newline at end of file diff --git a/results/scraper/fex/662 b/results/scraper/fex/662 new file mode 100644 index 000000000..37e994676 --- /dev/null +++ b/results/scraper/fex/662 @@ -0,0 +1,9 @@ +Investigate: Geekbench detects invalid CPU topology +When run with `-T 4` to report four threads, geekbench 4 detects the CPU topology as: + +> 4 Processors, 16 Cores + +[see full report](https://browser.geekbench.com/v4/cpu/15997950) + +I have no idea where it's getting 16 cores from, this is a 12 core system. + htop reports that It's only actually running 4 threads of execution, as expected. \ No newline at end of file diff --git a/results/scraper/fex/663 b/results/scraper/fex/663 new file mode 100644 index 000000000..e0ac691e1 --- /dev/null +++ b/results/scraper/fex/663 @@ -0,0 +1,2 @@ +gimp is broken +It used to work ~ 3 months ago. Needs to be compiled from source + figure out what's wrong. \ No newline at end of file diff --git a/results/scraper/fex/664 b/results/scraper/fex/664 new file mode 100644 index 000000000..4bf0046a8 --- /dev/null +++ b/results/scraper/fex/664 @@ -0,0 +1,10 @@ +Geekbench 4 crashes on arm64 host +Works fine on my x86 host, but on my c630, it gets: + +``` + Running HTML5 DOM +[ERROR] Unhandled JIT SIGBUS: PC: 0xffff7fcef674 Instruction: 0xb8e10094 + +corrupted size vs. prev_size +Aborted (core dumped) +``` \ No newline at end of file diff --git a/results/scraper/fex/667 b/results/scraper/fex/667 new file mode 100644 index 000000000..29be29a5c --- /dev/null +++ b/results/scraper/fex/667 @@ -0,0 +1 @@ +Geekbench 5 segfaults on "Running Camera" on arm host with -n 4000 diff --git a/results/scraper/fex/668 b/results/scraper/fex/668 new file mode 100644 index 000000000..e6e17a928 --- /dev/null +++ b/results/scraper/fex/668 @@ -0,0 +1,12 @@ +clang -mcpu/tune=native doesn't pick up Snapdragon 865 correctly +This is causing atomics to be terrible loadstore acquire/release pairs for everything outside of the JIT. +Even clang 11 is effected by this. + +First step would have our cmake script check for this and explicit place cortex-a77 there. +Also -march=native isn't supported on ARM with clang, so the current cmake check does nothing. It needs -mcpu or -mtune. + +Second step would be to upstream changes to clang/llvm so it is picked up correctly. This way it can be supported on at least clang 12. + +Might also effect Snapdragon 850, so c630 is also slower? + +Causing pain with interpreter cmpxchg fallback unit tests. \ No newline at end of file diff --git a/results/scraper/fex/672 b/results/scraper/fex/672 new file mode 100644 index 000000000..a7a59ca93 --- /dev/null +++ b/results/scraper/fex/672 @@ -0,0 +1,7 @@ +Unaligned atomics are unsupported for ARMv8.0 +On ARMv8.0, atomic operations are implemented using loadstore exclusive operations. +With #666 merged, unaligned cmpxchg{,8b} ops are supported on ARMv8.1. + +To support these on ARMv8.0 correctly, we need to capture the loadstore exclusive routines faulting, read the next few instructions to see what sort of op it is (Just data movement or one of the atomic memory ops?) and do the full operation in the signal handler using aligned CAS loops. + +Future looking work would be to signal that these blocks need to be recompiled with this directly in the block cache but we aren't there yet. \ No newline at end of file diff --git a/results/scraper/fex/675 b/results/scraper/fex/675 new file mode 100644 index 000000000..7ec46debc --- /dev/null +++ b/results/scraper/fex/675 @@ -0,0 +1,2 @@ +DeadStoreElim: Merge FPR and GPR logic +They are nearly identical, each one using a 32-bit uint bit-vector. They can be combined for more speed. See https://github.com/FEX-Emu/FEX/pull/670#discussion_r561849497 \ No newline at end of file diff --git a/results/scraper/fex/676 b/results/scraper/fex/676 new file mode 100644 index 000000000..dac289db6 --- /dev/null +++ b/results/scraper/fex/676 @@ -0,0 +1,4 @@ +If full visibility of x87 ops convert to 64bit with unsafe flags +If we have full visibility of the scope of an x87 op, we can unsafely convert to FP64. +Only enabled with unsafe flag. +Necessary for some x87 perf gains. \ No newline at end of file diff --git a/results/scraper/fex/677 b/results/scraper/fex/677 new file mode 100644 index 000000000..eff2193ba --- /dev/null +++ b/results/scraper/fex/677 @@ -0,0 +1,3 @@ +IR: Formalize OP_STORECONTEXTINDEXED to only access x87 or gdt +- Update validation pass to enforce the base offset +- Assume it can't access outside those regions in LSE/DSE \ No newline at end of file diff --git a/results/scraper/fex/678 b/results/scraper/fex/678 new file mode 100644 index 000000000..59fb001aa --- /dev/null +++ b/results/scraper/fex/678 @@ -0,0 +1,3 @@ +Investigate: GOG installer fails +Haven't checked this in a few months. Might be fine now. +Needs checked first \ No newline at end of file diff --git a/results/scraper/fex/679 b/results/scraper/fex/679 new file mode 100644 index 000000000..3885fe5d9 --- /dev/null +++ b/results/scraper/fex/679 @@ -0,0 +1 @@ +Clear warnings in the project diff --git a/results/scraper/fex/680 b/results/scraper/fex/680 new file mode 100644 index 000000000..f731573fa --- /dev/null +++ b/results/scraper/fex/680 @@ -0,0 +1,2 @@ +-T with more than 1 breaks a lot of things +dav1d is a good test for this. \ No newline at end of file diff --git a/results/scraper/fex/681 b/results/scraper/fex/681 new file mode 100644 index 000000000..619a1d041 --- /dev/null +++ b/results/scraper/fex/681 @@ -0,0 +1,3 @@ +Get SMC working with a memory watcher +Would be nice to use Soft dirty PTE for this, but the interface isn't something we can use. +Full userspace tracking with mirror support until soft dirty PTE gets wired correctly. \ No newline at end of file diff --git a/results/scraper/fex/682 b/results/scraper/fex/682 new file mode 100644 index 000000000..6a57c9ef7 --- /dev/null +++ b/results/scraper/fex/682 @@ -0,0 +1,2 @@ +Put rootfs in to filesystem file rather than forcing uncompressing +something like qcow2? \ No newline at end of file diff --git a/results/scraper/fex/683 b/results/scraper/fex/683 new file mode 100644 index 000000000..22c6dc9c2 --- /dev/null +++ b/results/scraper/fex/683 @@ -0,0 +1,2 @@ +Fex should be able to build FEX +Ninja works, clang fails with some internal error. Investigate and fix \ No newline at end of file diff --git a/results/scraper/fex/684 b/results/scraper/fex/684 new file mode 100644 index 000000000..6156d78ef --- /dev/null +++ b/results/scraper/fex/684 @@ -0,0 +1,2 @@ +Default rootfs(s) location +.fex-emu/<rootfsname>/.... or some other XDG correct path \ No newline at end of file diff --git a/results/scraper/fex/685 b/results/scraper/fex/685 new file mode 100644 index 000000000..73f785dbd --- /dev/null +++ b/results/scraper/fex/685 @@ -0,0 +1,2 @@ +Better default configuration +`-m -n 5000 -c irjit` should be default \ No newline at end of file diff --git a/results/scraper/fex/686 b/results/scraper/fex/686 new file mode 100644 index 000000000..5e133b446 --- /dev/null +++ b/results/scraper/fex/686 @@ -0,0 +1 @@ +Support multiple layers of rootfs, so we can overlay the thunks diff --git a/results/scraper/fex/687 b/results/scraper/fex/687 new file mode 100644 index 000000000..74c24c68f --- /dev/null +++ b/results/scraper/fex/687 @@ -0,0 +1,2 @@ +Binary distribution of rootfs + thunks +Depends on #684 and #686 \ No newline at end of file diff --git a/results/scraper/fex/688 b/results/scraper/fex/688 new file mode 100644 index 000000000..fbdf96791 --- /dev/null +++ b/results/scraper/fex/688 @@ -0,0 +1,2 @@ +User should not have to care about rootfs configuration +Depends on #687 + auto rootfs download \ No newline at end of file diff --git a/results/scraper/fex/689 b/results/scraper/fex/689 new file mode 100644 index 000000000..0ca46825c --- /dev/null +++ b/results/scraper/fex/689 @@ -0,0 +1,2 @@ +Make it easy to select rootfs by name +Depends on #684 \ No newline at end of file diff --git a/results/scraper/fex/69 b/results/scraper/fex/69 new file mode 100644 index 000000000..4b4153cdd --- /dev/null +++ b/results/scraper/fex/69 @@ -0,0 +1,3 @@ +Fix ELFLoader not searching in rootfs for dynamic linker +Currently if you're on a host that doesn't have a `/lib64/ld-linux-x86-64.so.2` then you need to explicitly point to the dynamic linker location. +Let it search in the rootfs first. \ No newline at end of file diff --git a/results/scraper/fex/690 b/results/scraper/fex/690 new file mode 100644 index 000000000..4c0939ee9 --- /dev/null +++ b/results/scraper/fex/690 @@ -0,0 +1,2 @@ +32bit VDSO +Sonicadvance1 implementing \ No newline at end of file diff --git a/results/scraper/fex/691 b/results/scraper/fex/691 new file mode 100644 index 000000000..3ea0d08cd --- /dev/null +++ b/results/scraper/fex/691 @@ -0,0 +1,2 @@ +BRK fixes +Sonicadvance1 implementing \ No newline at end of file diff --git a/results/scraper/fex/692 b/results/scraper/fex/692 new file mode 100644 index 000000000..978725e39 --- /dev/null +++ b/results/scraper/fex/692 @@ -0,0 +1,2 @@ +32bit allocator +Sonicadvance1 implementing \ No newline at end of file diff --git a/results/scraper/fex/693 b/results/scraper/fex/693 new file mode 100644 index 000000000..6bf667ba7 --- /dev/null +++ b/results/scraper/fex/693 @@ -0,0 +1,6 @@ +Investigate IR Caching / Preload +Minimal AOT implementation + +- Binary dump IR +- Pre-load IR dumps +- Add a mode where FEX pre-generates the dumps \ No newline at end of file diff --git a/results/scraper/fex/694 b/results/scraper/fex/694 new file mode 100644 index 000000000..3190d06d5 --- /dev/null +++ b/results/scraper/fex/694 @@ -0,0 +1,4 @@ +Optimize SIMD / SS fpu performance +- Make sure SS / SD opcodes don't to merges +- Optimize suffles +- Make sure SIMD generates good enough stuff \ No newline at end of file diff --git a/results/scraper/fex/695 b/results/scraper/fex/695 new file mode 100644 index 000000000..e29e206fe --- /dev/null +++ b/results/scraper/fex/695 @@ -0,0 +1,6 @@ +Have a landing page +Light gray / dark gray +- News / Blog +- Link to the wiki +- Mission statement +- What makes us different than qemu? \ No newline at end of file diff --git a/results/scraper/fex/696 b/results/scraper/fex/696 new file mode 100644 index 000000000..35c8d8e0f --- /dev/null +++ b/results/scraper/fex/696 @@ -0,0 +1 @@ +ioctl emulation to support non-patched kernels diff --git a/results/scraper/fex/697 b/results/scraper/fex/697 new file mode 100644 index 000000000..6bd732a52 --- /dev/null +++ b/results/scraper/fex/697 @@ -0,0 +1 @@ +Get ioctl32 patches upstreamed diff --git a/results/scraper/fex/699 b/results/scraper/fex/699 new file mode 100644 index 000000000..8126452f8 --- /dev/null +++ b/results/scraper/fex/699 @@ -0,0 +1,2 @@ +Remove Boost usage from cmake +We don't actually use it anymore, remove the requirement \ No newline at end of file diff --git a/results/scraper/fex/700 b/results/scraper/fex/700 new file mode 100644 index 000000000..0cd85d90e --- /dev/null +++ b/results/scraper/fex/700 @@ -0,0 +1,3 @@ +Setup automatic releases on tags +On new tag, have an action automatically create a release. +https://github.com/marketplace/actions/create-a-release \ No newline at end of file diff --git a/results/scraper/fex/702 b/results/scraper/fex/702 new file mode 100644 index 000000000..12f8e1bf7 --- /dev/null +++ b/results/scraper/fex/702 @@ -0,0 +1 @@ +IR: Make all constants sized diff --git a/results/scraper/fex/703 b/results/scraper/fex/703 new file mode 100644 index 000000000..cc43347c7 --- /dev/null +++ b/results/scraper/fex/703 @@ -0,0 +1,2 @@ +OpDisp: MB for 32-bit is broken +MB Calculations always do `uint64_t` math on RIP \ No newline at end of file diff --git a/results/scraper/fex/713 b/results/scraper/fex/713 new file mode 100644 index 000000000..86e3602ba --- /dev/null +++ b/results/scraper/fex/713 @@ -0,0 +1,24 @@ +Investigate gcc-target-test failures +Follow up from #712 + +Current fail list +``` +# these fail on x86 and arm +pr88240.c.gcc-target-test-64 +sse2-mmx-cvtps2pi.c.gcc-target-test-64 +sse2-mmx-cvttps2pi.c.gcc-target-test-64 +sse2-mmx-pextrw.c.gcc-target-test-64 +sse2-mmx-psraw.c.gcc-target-test-64 +sse2-mmx-psrawi.c.gcc-target-test-64 +sse2-psraw-1.c.gcc-target-test-64 +sse2-shiftqihi-constant-2.c.gcc-target-test-64 + +# these fail on arm +sse2-mmx-pslld.c.gcc-target-test-64 +sse2-mmx-psllq.c.gcc-target-test-64 +sse2-mmx-psllw.c.gcc-target-test-64 +sse2-mmx-psrad.c.gcc-target-test-64 +sse2-mmx-psrld.c.gcc-target-test-64 +sse2-mmx-psrlq.c.gcc-target-test-64 +sse2-mmx-psrlw.c.gcc-target-test-64 +``` \ No newline at end of file diff --git a/results/scraper/fex/714 b/results/scraper/fex/714 new file mode 100644 index 000000000..39f3dd7c4 --- /dev/null +++ b/results/scraper/fex/714 @@ -0,0 +1,4 @@ +Investigate gcc-target-tests-32 failing to launch on CI +Follow up from #704 + +Likely some rootfs issue \ No newline at end of file diff --git a/results/scraper/fex/720 b/results/scraper/fex/720 new file mode 100644 index 000000000..282076e1b --- /dev/null +++ b/results/scraper/fex/720 @@ -0,0 +1,5 @@ +cmake: Externals shouldn't leak their include paths into global space +It pollutes all the compile commands with things like: + +`-I../External/cpp-optparse -I../External/imgui -I../External/json-maker -I../External/tiny-json -I../External/xbyak` + diff --git a/results/scraper/fex/726 b/results/scraper/fex/726 new file mode 100644 index 000000000..4967216b0 --- /dev/null +++ b/results/scraper/fex/726 @@ -0,0 +1 @@ +Cmake don't build thunks by default diff --git a/results/scraper/fex/727 b/results/scraper/fex/727 new file mode 100644 index 000000000..e1ffcbfa7 --- /dev/null +++ b/results/scraper/fex/727 @@ -0,0 +1,2 @@ +Zenity crashes on exit +It calls exit_group twice, and threads get the exit signal twice \ No newline at end of file diff --git a/results/scraper/fex/729 b/results/scraper/fex/729 new file mode 100644 index 000000000..34f2d73a7 --- /dev/null +++ b/results/scraper/fex/729 @@ -0,0 +1 @@ +Cmake should error when python3 isn't installed diff --git a/results/scraper/fex/743 b/results/scraper/fex/743 new file mode 100644 index 000000000..e768fd0a2 --- /dev/null +++ b/results/scraper/fex/743 @@ -0,0 +1,3 @@ +32bit recvmsg is still broken. +Causes OpenAL problems. +Terminal complaints about memfd only returning 1 fd. \ No newline at end of file diff --git a/results/scraper/fex/744 b/results/scraper/fex/744 new file mode 100644 index 000000000..ac33bd586 --- /dev/null +++ b/results/scraper/fex/744 @@ -0,0 +1,2 @@ +32bit msgctl broken on ARM +msgrcv and msgsnd might also be a part of this. Needs to be double checked. \ No newline at end of file diff --git a/results/scraper/fex/745 b/results/scraper/fex/745 new file mode 100644 index 000000000..eccc36c3d --- /dev/null +++ b/results/scraper/fex/745 @@ -0,0 +1 @@ +32bit semctl is broken on ARM diff --git a/results/scraper/fex/75 b/results/scraper/fex/75 new file mode 100644 index 000000000..03aa3d1a6 --- /dev/null +++ b/results/scraper/fex/75 @@ -0,0 +1,6 @@ +Support CMPXCHG16B +Requires adding another GPR class to the RA that supports paired registers. +Then adding support for class interference support to the RA. +Probably will lead in to a bit of IR Op and RA cleanup in the process. +It's a useful instruction for lock free linked list implementations that people will definitely be using. +Also ensure the CPUID bit says it is supported \ No newline at end of file diff --git a/results/scraper/fex/753 b/results/scraper/fex/753 new file mode 100644 index 000000000..e28fa6139 --- /dev/null +++ b/results/scraper/fex/753 @@ -0,0 +1,16 @@ +EmulatedFDManager::OpenAt breaks when reopening anonymous objects via /proc/self/fd +Not sure if any sane guest would do this. + +But if a guest was to open a socket or memfd (anything which isn't backed by a real path) and then tries to re-open it via the `/proc/self/fd/` handle, our syscall emulation crashes. + +the following gvisor tests do this: + + * memfd_test.jit.gvisor + * proc_test.jit.gvisor + * socket_abstract_test.jit.gvisor + * socket_filesystem_test.jit.gvisor + * socket_unix_pair_test.jit.gvisor + +The issue is that when `EmulatedFDManager::OpenAt` tries to resolve the canonical, absolute path, `std::filesystem::canonical` throws an exception because it obviously doesn't resolve an absolute path. + +The fix is probably just catching the exception and returning -1 when this happens. \ No newline at end of file diff --git a/results/scraper/fex/757 b/results/scraper/fex/757 new file mode 100644 index 000000000..a01b9c3eb --- /dev/null +++ b/results/scraper/fex/757 @@ -0,0 +1,3 @@ +Clean up error message about not being able to find guest interpreter +Currently it just yells "Couldn't load dynamic ELF file's interpreter" +We should add detailed message about missing rootfs or bad rootfs and how to rectifying it. \ No newline at end of file diff --git a/results/scraper/fex/758 b/results/scraper/fex/758 new file mode 100644 index 000000000..71885a5c3 --- /dev/null +++ b/results/scraper/fex/758 @@ -0,0 +1,5 @@ +Make artifact file moving not fail +If a unit test pass fails early then all additional tests are skipped. +Currently all ctest result files are moved even if those tests didn't run. +These moves will fail and look like additional spurious failure +Add something like a `|| true` at the end of those moves so they don't look like additional failures. \ No newline at end of file diff --git a/results/scraper/fex/760 b/results/scraper/fex/760 new file mode 100644 index 000000000..4322ac364 --- /dev/null +++ b/results/scraper/fex/760 @@ -0,0 +1,3 @@ +Clean up thread state on exit +When a thread exits we don't fully clean up its state until process end. Effectively this leaks memory. +Clean it up and test with a fork bomb application. \ No newline at end of file diff --git a/results/scraper/fex/761 b/results/scraper/fex/761 new file mode 100644 index 000000000..a1351f0ec --- /dev/null +++ b/results/scraper/fex/761 @@ -0,0 +1,10 @@ +Implement Intel style cross-cacheline atomics with ARM TME +We don't currently have a CPU architecture that supports TME but we should track this. +Any atomic operation that crosses a cacheline will fault on ARM. +We then need to do two CAS loops to implement this. +Problem is that this can tear. + +Intel works around this problem by supporting "Split locks" +AMD should also just tear in this situation. + +Once we have an architecture that supports TME, use it to hold ownership of both sides of the cacheline and do the ops to ensure no tearing. \ No newline at end of file diff --git a/results/scraper/fex/762 b/results/scraper/fex/762 new file mode 100644 index 000000000..c18aa402d --- /dev/null +++ b/results/scraper/fex/762 @@ -0,0 +1,4 @@ +Improve RA handling with multi-blocks +Currently register allocation is not very aware of multiblock and inserts a bunch of extra spills to make room for registers that will be jumped over. + +LiveRanges need to be modified to follow branches. \ No newline at end of file diff --git a/results/scraper/fex/765 b/results/scraper/fex/765 new file mode 100644 index 000000000..131bba7ae --- /dev/null +++ b/results/scraper/fex/765 @@ -0,0 +1,3 @@ +Switch getdents over to 32bit syscall API once supported in 32bit process +Depending on 32bit or 64bit the API returns different results which can break things like llseek. +Currently semi-broken because of this. \ No newline at end of file diff --git a/results/scraper/fex/767 b/results/scraper/fex/767 new file mode 100644 index 000000000..a4f0c4f33 --- /dev/null +++ b/results/scraper/fex/767 @@ -0,0 +1,23 @@ +dav1d errors while decoding tiles +When running dav1d in single-threadded mode under Fex, it reliably errors out at around frame 121 of the linked test file. + +``` +dav1d 0.8.1 - by VideoLAN +Decoded 121/8929 frames (1.4%) - 16.42/1784.02 fps (0.01x)Error decoding frame: Invalid argument +``` + +I've traced the error to this line of code, which is failing an error check, but it's not the source of the error: +https://code.videolan.org/videolan/dav1d/-/blob/2e73051c57a1b2c28c46f72f9edec62f299ebac5/src/decode.c#L2542 + +It hits the same error in multithreadding mode too, but due to [bugs in dav1d](https://code.videolan.org/videolan/dav1d/-/issues/277) it suppresses the error and just returns invalid results. (Or deadlocks when run under current versions of fex, but that might be a bug in dav1d) + +The real error might be from a frame or two eariler, I've noticed that it slows down while decoding frame 121. + +it also fails with `-c irjit -n1` and `-c irint -n 500`. I suspect this might be an issue in syscall emulation, or maybe a bug in a single instruction. + +## Steps to reproduce: + +Download the Chimera-AV1-8bit-1920x1080-6736kbps.ivf test file from netflix: http://download.opencontent.netflix.com/?prefix=AV1/Chimera/Old/ + +Run with the following Command line: +`FEXLoader -t 1 -- dav1d --framethreads 1 --tilethreads 1 -i Chimera-AV1-8bit-1920x1080-6736kbps.ivf -o test.md5` diff --git a/results/scraper/fex/770 b/results/scraper/fex/770 new file mode 100644 index 000000000..e2ae390e1 --- /dev/null +++ b/results/scraper/fex/770 @@ -0,0 +1,2 @@ +Implement BCD unit tests +They are missing from initial x87 BCD implementation \ No newline at end of file diff --git a/results/scraper/fex/771 b/results/scraper/fex/771 new file mode 100644 index 000000000..46943e63c --- /dev/null +++ b/results/scraper/fex/771 @@ -0,0 +1,15 @@ +Investigate: intermittent crash in Geekbench 4's llvm benchmark +This might be related to the multithreading issues, but I'm creating this issue to remind me to check later after multithreadding (#680) and reclusive terminate bugs are fixed. + +Also after #683 + +``` +$ Bin/FEXLoader -s -T 8 -- ../../Geekbench-4.4.4-Linux/geekbench_x86_64 --section 2 --workload 212 +Geekbench 4.4.4 Pro : http://www.geekbench.com/ + +terminate called recursively +terminate called after throwing an instance of 'terminate called recursively +terminate called recursively +std::bad_alloc' + what(): std::bad_alloc +``` \ No newline at end of file diff --git a/results/scraper/fex/772 b/results/scraper/fex/772 new file mode 100644 index 000000000..fc61187bf --- /dev/null +++ b/results/scraper/fex/772 @@ -0,0 +1,4 @@ +GDBServer: Dead threads aren't cleared out +They just stick around forever, with their program counter pointing at a syscall to `sys_exit` in pthread's `start_thread` + +Probably related to #760 \ No newline at end of file diff --git a/results/scraper/fex/773 b/results/scraper/fex/773 new file mode 100644 index 000000000..d608fc222 --- /dev/null +++ b/results/scraper/fex/773 @@ -0,0 +1,6 @@ +GDBServer: info regs invalid when in syscall +Simple solution (aka workaround) is to optionally flush the context before syscalls when the the gdb server is active. + +Complex solution is to generate some kind of unwinding data from our codegen which allows rebuilding of the context at any point (or any sync point such as memory reads and syscalls). + +The complex solution might be useful for other things later, like providing correct contexts for segfaults \ No newline at end of file diff --git a/results/scraper/fex/774 b/results/scraper/fex/774 new file mode 100644 index 000000000..45dffa1c7 --- /dev/null +++ b/results/scraper/fex/774 @@ -0,0 +1,2 @@ +CS:GO Intro video corruption + diff --git a/results/scraper/fex/775 b/results/scraper/fex/775 new file mode 100644 index 000000000..26b7bf88c --- /dev/null +++ b/results/scraper/fex/775 @@ -0,0 +1,5 @@ +Investigate aarch64 flag extentions +Flag manipulation instructions v1 +Flag manipulation instructions v2 + +These might help us do fast emulation of x86 flags \ No newline at end of file diff --git a/results/scraper/fex/776 b/results/scraper/fex/776 new file mode 100644 index 000000000..b2e34ae7f --- /dev/null +++ b/results/scraper/fex/776 @@ -0,0 +1 @@ +If compiled on x86_64, throw a performance error message in cmake first. Then allow it to be disabled with `-DENABLE_X86_HOST_DEBUG=True` diff --git a/results/scraper/fex/777 b/results/scraper/fex/777 new file mode 100644 index 000000000..c850625e4 --- /dev/null +++ b/results/scraper/fex/777 @@ -0,0 +1,4 @@ +GDBServer: Crashes due to initialisation order issue. +Currently crashes if `FEXCore::Config::SetConfig(CTX, FEXCore::Config::CONFIG_GDBSERVER, ...)` is called before `FEXCore::Context::SetSignalDelegator()` + +Probably need to delay initialisation of the GdbServer until `InitCore()` is called. \ No newline at end of file diff --git a/results/scraper/fex/779 b/results/scraper/fex/779 new file mode 100644 index 000000000..361147e14 --- /dev/null +++ b/results/scraper/fex/779 @@ -0,0 +1 @@ +Write x87 tests for FIST*T*P, Rounding Control, Precision Control diff --git a/results/scraper/fex/780 b/results/scraper/fex/780 new file mode 100644 index 000000000..e6fe6ce88 --- /dev/null +++ b/results/scraper/fex/780 @@ -0,0 +1,2 @@ +x87: X87FNSAVE does not initialize fpu +It should set FCW, FSW, FTW to their default values \ No newline at end of file diff --git a/results/scraper/fex/782 b/results/scraper/fex/782 new file mode 100644 index 000000000..584ee3810 --- /dev/null +++ b/results/scraper/fex/782 @@ -0,0 +1,7 @@ +x87: Correctly implement FREM +Follow up from #781 + +We need to +- Handle only up to 64 exponent diffs per step +- Set C0, C1, C3 based on the result +- Have tests \ No newline at end of file diff --git a/results/scraper/fex/786 b/results/scraper/fex/786 new file mode 100644 index 000000000..b1e193dda --- /dev/null +++ b/results/scraper/fex/786 @@ -0,0 +1,2 @@ +Expand sar tests +We don't test for sign extension for 8 and 16 bit SARs, possibly 32 and 64 bit ones need to be added too. \ No newline at end of file diff --git a/results/scraper/fex/787 b/results/scraper/fex/787 new file mode 100644 index 000000000..36b3357a7 --- /dev/null +++ b/results/scraper/fex/787 @@ -0,0 +1,2 @@ +glibc 2.33 silently fails +~~No error, just segfaults somewhere in /usr/lib/ld-2.33.so~~ I'm confused, not sure whats happening \ No newline at end of file diff --git a/results/scraper/fex/788 b/results/scraper/fex/788 new file mode 100644 index 000000000..574d1efa5 --- /dev/null +++ b/results/scraper/fex/788 @@ -0,0 +1,8 @@ +AUXV values are wrong +- AT_PHDR doesn't point to the header (crashes ldconfig), it also points to the interpreter when not static elf +- AT_PHNUM doesn't match host value (maybe it is set from the interpreter instead of the program ?) +- AT_ENTRY points to the interpreter entrypoint +- *IDs are fixed to 1000, not the current user information +- AT_HWCAP is set to 0 (bfebfbff on my laptop for 64 bit process) +- AT_HWCAP2 doesn't exist in guest +- AT_SYSINFO shouldn't exist for x86-64 binaries \ No newline at end of file diff --git a/results/scraper/fex/791 b/results/scraper/fex/791 new file mode 100644 index 000000000..e1935910e --- /dev/null +++ b/results/scraper/fex/791 @@ -0,0 +1,3 @@ +Geekbench4 uses LOCK on BTS +Luckily implementing LOCK on BTS, BTC, BTR isn't too terrible. +Noticed when adding assert checks on all the missing ops that use LOCK. \ No newline at end of file diff --git a/results/scraper/fex/796 b/results/scraper/fex/796 new file mode 100644 index 000000000..365b1e066 --- /dev/null +++ b/results/scraper/fex/796 @@ -0,0 +1 @@ +Goals: User & Dev Usability / Compatibility / Cleanups diff --git a/results/scraper/fex/797 b/results/scraper/fex/797 new file mode 100644 index 000000000..191dadd53 --- /dev/null +++ b/results/scraper/fex/797 @@ -0,0 +1,2 @@ +aotir: Optimize hash function +Either via 2xcrc32 or xxh3. Also move to a util file so it is reusable. \ No newline at end of file diff --git a/results/scraper/fex/798 b/results/scraper/fex/798 new file mode 100644 index 000000000..bd7b2175d --- /dev/null +++ b/results/scraper/fex/798 @@ -0,0 +1,2 @@ +aotir: Hash function chunks, not min-max +Functions have large holes, and we often accidentally merge two functions \ No newline at end of file diff --git a/results/scraper/fex/799 b/results/scraper/fex/799 new file mode 100644 index 000000000..72904a3bf --- /dev/null +++ b/results/scraper/fex/799 @@ -0,0 +1,4 @@ +IR: Add a flag for OPs that are valid arguments but don't have dst +- OP_INLINECONSTANT +- OP_INLINEENTRYPOINT +- OP_HEADER \ No newline at end of file diff --git a/results/scraper/fex/800 b/results/scraper/fex/800 new file mode 100644 index 000000000..c02fd5b02 --- /dev/null +++ b/results/scraper/fex/800 @@ -0,0 +1,2 @@ +Syscalls: Forked process shouldn't join thread that started before the fork +This breaks gvsisor's futex tests, as pthread crashes when the child process tries to join() during teardown \ No newline at end of file diff --git a/results/scraper/fex/802 b/results/scraper/fex/802 new file mode 100644 index 000000000..f3691559c --- /dev/null +++ b/results/scraper/fex/802 @@ -0,0 +1,6 @@ +Deal with Robust list handling +For x86_64, the guest glibc's set_robust_list syscall just overrides the host glibc robust list. Which might be fine if fex itself never needs robust futexs. + +But this gets iffy with thunks and libraries. + +For x86_32, we just discard the guest robust list, which is problematic. \ No newline at end of file diff --git a/results/scraper/fex/804 b/results/scraper/fex/804 new file mode 100644 index 000000000..25f0255d0 --- /dev/null +++ b/results/scraper/fex/804 @@ -0,0 +1,7 @@ +Thunks are broken? +I can't get thunks working on an AArch64 host. +We need a guide on how to get these to work. +Tried installing to the precompiled rootfs (Just overwrite a bunch of the libraries with the same versioned libraries?) and it just tried calling some thunked function (that didn't exist as a hash?) and explodes. +This is completely blocking for anyone wanting to toy with thunks. + +See the discussion on Discord, even me throwing an hour or two of time at the problem, couldn't figure out why things weren't working. \ No newline at end of file diff --git a/results/scraper/fex/806 b/results/scraper/fex/806 new file mode 100644 index 000000000..3592aa67b --- /dev/null +++ b/results/scraper/fex/806 @@ -0,0 +1,6 @@ +Code Flushing: Remove stale code from all theards +Follow up from #705 + +"Derek Bruening's [PhD thesis](http://www.burningcutlery.com/derek/docs/phd.pdf) describes a system for invalidating code blocks (called "fragments") across multiple thread. The relevant part starts on page 156. + +However it is quite complex: you need to be able to hotpatch branch instructions and update lookup tables while another thread is executing translated code. At that point it might be worth simply switching to a single shared code cache, which has many other benefits. See [this paper](http://www.burningcutlery.com/derek/docs/threadshared-CGO06.pdf) for details on implementing a thread-shared code cache." (via @Amanieu) \ No newline at end of file diff --git a/results/scraper/fex/807 b/results/scraper/fex/807 new file mode 100644 index 000000000..ce6bdc414 --- /dev/null +++ b/results/scraper/fex/807 @@ -0,0 +1,4 @@ +Code Flushing: Improve tracking data structures +Follow up from #705 + +Having page lists in a map might be a good solution, but we probably need to look into some better data structures. \ No newline at end of file diff --git a/results/scraper/fex/808 b/results/scraper/fex/808 new file mode 100644 index 000000000..eb3366ef7 --- /dev/null +++ b/results/scraper/fex/808 @@ -0,0 +1,6 @@ +Code Invalidation: RemoveCode shouldn't free IRLists, as that breaks self-invalidation in interpreter +Follow up from #705 + +If the interpreter invalidates (either via syscall, or op_removecodeentry) it needs to run the current block to the block exit. We should "stage" removed code blocks to a "to free" list, and GC them at a point where we're sure we're not running them. + +This doesn't affect the jit as it doesn't reference the ir data during runtime \ No newline at end of file diff --git a/results/scraper/fex/809 b/results/scraper/fex/809 new file mode 100644 index 000000000..2c5ecfb02 --- /dev/null +++ b/results/scraper/fex/809 @@ -0,0 +1,29 @@ +Support mixture of guest and host robust futexes +We can't safely modify the guest's robust list + - Memory might not be sufficient, or it will just overwrite our additions on change +We also can't safely consume the full guest robust and append it to our own + - We don't have a full view of glibc's robust list + - Might work if we capture all HOST get/set lists and modifying it? Needs seccomp filters then. + - Would require us to track our own list, append the glibc head to our tail, and append the guest one to that tail as well. + - Same problem where host glibc could potentially overwrite the and end that contains the guest. + - Can't guarantee no host robust-futex usage due to thunks. + We have no interface in to setting 32bit robust list + - Needs the syscall32 API + +Proposal to the kernel? +- New robust list indexing API? +- Something that uses the key api? +- long set_robust_list_key(key_t key, struct robust_list_head *head, size_t len, int listflg); + - IPC_CREAT - Create a new robust list associated with key + - IPC_EXCL - same to ensure the syscall fails if already created +- long get_robust_list_key(key_t key, int pid, struct robust_list_head **head_ptr, + size_t *len_ptr); +- long del_robust_list_key(key_t key); + - Disassociates robust list of key from process and deletes? + +Allows us to create multiple robust lists tied to a pid. +Still have the regular get/set robust list path, just additional list arrays on top of that. +Expectation is to only have a handful of robust lists, can be a linear scan lookup. +Expose the 32bit path through the "regular" 32bit syscall path. + +I'm already dreading bringing this up on the mailing list. \ No newline at end of file diff --git a/results/scraper/fex/819 b/results/scraper/fex/819 new file mode 100644 index 000000000..a0e376d50 --- /dev/null +++ b/results/scraper/fex/819 @@ -0,0 +1,6 @@ +Deduplicate 3 tables in Config.cpp +In Config.cpp we have three tables that duplicate a bit of information. +Clean this up to remove duplication and tie the config enums to config option name and environment variable stronger. +Maybe also just define the data with the enum in FEXCore config enum. + +`std::map<>ConfigToNameLookup`, `std::map<>ConfigLookup`, `std::array<>ConfigLookup` is the duplicated data. \ No newline at end of file diff --git a/results/scraper/fex/824 b/results/scraper/fex/824 new file mode 100644 index 000000000..88a0a8de4 --- /dev/null +++ b/results/scraper/fex/824 @@ -0,0 +1,4 @@ +Go through every instruction and ensure LOCK *support* +We missed LOCK on some ALU ops just recently from #823. +We should go through all the OpDispatcher implementations to ensure we are supporting LOCK +At least an assert on the ones we don't support like we currently do. \ No newline at end of file diff --git a/results/scraper/fex/835 b/results/scraper/fex/835 new file mode 100644 index 000000000..126ef14d9 --- /dev/null +++ b/results/scraper/fex/835 @@ -0,0 +1,3 @@ +Move JIT core's HandleGuestSignal outside of the regular JIT code +This has linux-isms in it so it should live with the SignalDelegator. +Since this will heavily change depending on which OS we are targeting. \ No newline at end of file diff --git a/results/scraper/fex/840 b/results/scraper/fex/840 new file mode 100644 index 000000000..a316faba4 --- /dev/null +++ b/results/scraper/fex/840 @@ -0,0 +1,4 @@ +Wrap /proc/version to not leak host kernel information +This leaks kernel information. Which is why some applications are using too new of syscalls. +On my current x86 host this file contains +```Linux version 5.10.0-14-generic (buildd@lcy01-amd64-009) (gcc (Ubuntu 10.2.1-6ubuntu2) 10.2.1 20210121, GNU ld (GNU Binutils for Ubuntu) 2.36) #15-Ubuntu SMP Fri Jan 29 15:10:03 UTC 2021``` \ No newline at end of file diff --git a/results/scraper/fex/844 b/results/scraper/fex/844 new file mode 100644 index 000000000..86786a075 --- /dev/null +++ b/results/scraper/fex/844 @@ -0,0 +1,2 @@ +Implement LOCK NEG +This requires a CAS loop in the backend to implement. Additionally we need more infrastructure in the signal handler to handle the unaligned case. \ No newline at end of file diff --git a/results/scraper/fex/845 b/results/scraper/fex/845 new file mode 100644 index 000000000..97c8ce0ca --- /dev/null +++ b/results/scraper/fex/845 @@ -0,0 +1,3 @@ +Go through every instruction and ensure segment prefixing supporting +We may be missing segment prefixing on instructions. +Go through all of them and ensure we haven't missed any. \ No newline at end of file diff --git a/results/scraper/fex/846 b/results/scraper/fex/846 new file mode 100644 index 000000000..e9f5d647f --- /dev/null +++ b/results/scraper/fex/846 @@ -0,0 +1,22 @@ +Parent thread not exiting +Reproduction: + +``` bash +count=0; while : +do +let "count+=1"; Bin/FEXLoader -T 4 -s --aotir-load -- ../../Geekbench-4.4.4-Linux/geekbench_x86_64 --section 2 --workload 213 && echo worked $count +sleep 1 +done +``` + +Seems to crash sometimes after 10+ iterations on my machine. If you attach with GDB, there is only one thread with the following backtrace: +``` +(gdb) bt +#0 0x00007fe468cec9ba in __futex_abstimed_wait_common64 () from /usr/lib/libpthread.so.0 +#1 0x00007fe468ce6260 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 +#2 0x00007fe468bb5bb1 in __gthread_cond_wait (__mutex=<optimized out>, __cond=<optimized out>) + at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:865 +#3 std::condition_variable::wait (this=<optimized out>, __lock=...) at /build/gcc/src/gcc/libstdc++-v3/src/c++11/condition_variable.cc:53 +#4 0x00005635538ea6eb in FEXCore::Context::Context::RunUntilExit() () +#5 0x00005635538ddc9c in main () +``` \ No newline at end of file diff --git a/results/scraper/fex/847 b/results/scraper/fex/847 new file mode 100644 index 000000000..dd6dab908 --- /dev/null +++ b/results/scraper/fex/847 @@ -0,0 +1,14 @@ +Geekbench 4 Camera max-threads rare deadlock +This is rare, semi-reproducible you need to loop with -T the same as host + +```bash +count=0; while : +do +let "count+=1"; Bin/FEXLoader -T 24 -s --aotir-load -- ../../Geekbench-4.4.4-Linux/geekbench_x86_64 --section 2 --workload 213 && echo worked $count +sleep 1 +done +``` + +When you hit a deadlock, you can gdb attach and see all threads are in a futex syscall, and they are all waiting on the same futex: + +in gdb you can use `thread apply all print/x $rdi` to print out which futex each thread is on diff --git a/results/scraper/fex/85 b/results/scraper/fex/85 new file mode 100644 index 000000000..c1c595be6 --- /dev/null +++ b/results/scraper/fex/85 @@ -0,0 +1,4 @@ +Improve performance of the register allocator +The register allocator becomes a fairly large time sink in large functions. +This needs to be improved quite substantially. +Additionally the cmpxchg instruction is going to add a paired register class which will add register class interference testing, which could drive up CPU usage more. \ No newline at end of file diff --git a/results/scraper/fex/854 b/results/scraper/fex/854 new file mode 100644 index 000000000..e702d7152 --- /dev/null +++ b/results/scraper/fex/854 @@ -0,0 +1,5 @@ +Add error handling for memory allocation in TestHarnessRunner +It's confusing when the test harness runner inexplicably fails because of memory allocation problems. +This can be reproduced by enabling ASAN and trying to run tests through the test harness runner. + +Just needs error handling added to the memory allocation to see why it failed. \ No newline at end of file diff --git a/results/scraper/fex/855 b/results/scraper/fex/855 new file mode 100644 index 000000000..c1294097b --- /dev/null +++ b/results/scraper/fex/855 @@ -0,0 +1,2 @@ +Enabled Invariant TSC CPUID +I keep forgetting to enable this. \ No newline at end of file diff --git a/results/scraper/fex/86 b/results/scraper/fex/86 new file mode 100644 index 000000000..1f0504306 --- /dev/null +++ b/results/scraper/fex/86 @@ -0,0 +1,6 @@ +Implement code segment dumping +Related to #85. +Allow dumping of code from an arbitrary PC, storing relevant data to allow running standalone from the application executing. +Needs to store state like RIP, Allocated memory regions, Incoming state, outgoing state(?Might not be worth hassle), and potentially accessed memory region data +This will be useful for microbenching RA on large functions very specifically. +Ensuring runtime correctness of the ripped out code is something second to care about. \ No newline at end of file diff --git a/results/scraper/fex/862 b/results/scraper/fex/862 new file mode 100644 index 000000000..d3fd12386 --- /dev/null +++ b/results/scraper/fex/862 @@ -0,0 +1,3 @@ +Check CPUID function 15h for RDTSC information +Apparently some new CPUs have documented this to allow getting true timer precision? +Double check documentation about this. \ No newline at end of file diff --git a/results/scraper/fex/866 b/results/scraper/fex/866 new file mode 100644 index 000000000..6541caa2c --- /dev/null +++ b/results/scraper/fex/866 @@ -0,0 +1,2 @@ +Ensure all systemcalls auxiliary structures are multi threading safe +Follow up from #865, some parts of that code are from before multi threading was a concern. \ No newline at end of file diff --git a/results/scraper/fex/867 b/results/scraper/fex/867 new file mode 100644 index 000000000..eadd006d4 --- /dev/null +++ b/results/scraper/fex/867 @@ -0,0 +1,3 @@ +Wiki had spam, add protections +Looks like we're the wiki has finally been hit by bots. +New account creation is disabled until I can add protections. \ No newline at end of file diff --git a/results/scraper/fex/868 b/results/scraper/fex/868 new file mode 100644 index 000000000..1da00ab86 --- /dev/null +++ b/results/scraper/fex/868 @@ -0,0 +1,5 @@ +Improve README.md +```it would be nice if in the project's github readme.md someone did put full procedure to get started +like dependencies install, and all commands needed to get it running, sort of like what you did with your comment in the issue i linked earlier, but with accuracy .. as in: it would work, no forgotten option, it would work for suggested environment, i mean actualy tested commands that result in a usable environment. that part is lacking and that's a bit limiting as for entry point into the project. it doesn't need to be very long, something like your comment on the issue, but accurate. +mentioning the required environment, telling it works in virtualized linux, using ubuntu version xx.xx .. i think, maybe all in all under 50 lines readme.md``` +I'm on it \ No newline at end of file diff --git a/results/scraper/fex/869 b/results/scraper/fex/869 new file mode 100644 index 000000000..9878dc735 --- /dev/null +++ b/results/scraper/fex/869 @@ -0,0 +1,3 @@ +Have ELFLoader resolve Ubuntu's broken symlink to dynamic linker +This is causing user confusion. +Check if it is a symlink, find the target of that symlink, append it to the rootfs location. \ No newline at end of file diff --git a/results/scraper/fex/87 b/results/scraper/fex/87 new file mode 100644 index 000000000..1fac2ded2 --- /dev/null +++ b/results/scraper/fex/87 @@ -0,0 +1,4 @@ +Implement RA constraints +We need RA constraints in order to remove extraneous moves inside of IR Ops. +A good example is the AArch64 instruction `casp*` needs the constraint that dest = expected to remove four moves per op. +There are a lot of other ops that would also benefit from RA constraints by just looking for moves in the aarch64 JIT. \ No newline at end of file diff --git a/results/scraper/fex/871 b/results/scraper/fex/871 new file mode 100644 index 000000000..6eb7edb2c --- /dev/null +++ b/results/scraper/fex/871 @@ -0,0 +1,2 @@ +x87: Implement FTW +FTW doesn't even exist on the context. We always write as zero atm, and never read. \ No newline at end of file diff --git a/results/scraper/fex/873 b/results/scraper/fex/873 new file mode 100644 index 000000000..92434353d --- /dev/null +++ b/results/scraper/fex/873 @@ -0,0 +1,2 @@ +Expand paths for config options +Without an absolute path some newfstatat commands fail. \ No newline at end of file diff --git a/results/scraper/fex/874 b/results/scraper/fex/874 new file mode 100644 index 000000000..48a23212c --- /dev/null +++ b/results/scraper/fex/874 @@ -0,0 +1,2 @@ +Change FEXConfig defaults +Its default selection isn't using true defaults. Was just some random values I threw in \ No newline at end of file diff --git a/results/scraper/fex/88 b/results/scraper/fex/88 new file mode 100644 index 000000000..aa7caf640 --- /dev/null +++ b/results/scraper/fex/88 @@ -0,0 +1,5 @@ +Implement RA reg class conflict support +We need to support register class conflicts in the RA. +This is because we need the regular GPR class, and an additional GPR pair class. +AArch64 CASP instructions mandate that the Expected and Desired arguments are two pairs of registers that are consecutive and start at an even offset. +So we need register pairs in one class `{x0, x1}, {x2, x3}, ...` That conflict with the regular GPR class when those are in use `x0, x1, x2, x3,...` \ No newline at end of file diff --git a/results/scraper/fex/881 b/results/scraper/fex/881 new file mode 100644 index 000000000..d4f8214cb --- /dev/null +++ b/results/scraper/fex/881 @@ -0,0 +1,5 @@ +Shadwen has video decoder issues +Game launches but the video intro cinematic has video decoder corruption. +Otherwise seems to run. + +[https://cdn.discordapp.com/attachments/765304672579092511/823672593151819846/image0.jpg](url) \ No newline at end of file diff --git a/results/scraper/fex/882 b/results/scraper/fex/882 new file mode 100644 index 000000000..506eaea70 --- /dev/null +++ b/results/scraper/fex/882 @@ -0,0 +1,10 @@ +Vector instruction failures +sse2-mmx-psllq +sse2-mmx-psllw +sse2-mmx-psraw +sse2-mmx-psrad +sse2-mmx-psrld +sse2-mmx-psrlq +sse2-mmx-psrlw + +Likely to be shift amount overflow handling \ No newline at end of file diff --git a/results/scraper/fex/889 b/results/scraper/fex/889 new file mode 100644 index 000000000..c94c4ab0f --- /dev/null +++ b/results/scraper/fex/889 @@ -0,0 +1,4 @@ +Fix potential leaks when forking with multiple threads +Some of this work was done in #883 + +But there are still potential leaks around both TLS and heap allocated objects. See FIXMEs in comments for more details about what needs investigating and fixing. \ No newline at end of file diff --git a/results/scraper/fex/893 b/results/scraper/fex/893 new file mode 100644 index 000000000..3e396181a --- /dev/null +++ b/results/scraper/fex/893 @@ -0,0 +1,6 @@ +Thunks don't pick up environment variables declared through FEX config files +Currently if you use thunks and set environment variables, then thunked libraries will miss those environment variables. + +This is easy to see by thunking libGL and setting vblank_mode=0 for testing. + +We most likely want to pass these new environment variables through setenv once config is load and only if thunks are used. \ No newline at end of file diff --git a/results/scraper/fex/894 b/results/scraper/fex/894 new file mode 100644 index 000000000..fd55738d2 --- /dev/null +++ b/results/scraper/fex/894 @@ -0,0 +1,3 @@ +Knights of the old republic 2 crashes with strange error +This is a 32bit game and it crashes with std::system_error bits. +Neverwinter nights is the same engine and runs so very strange that it fails. \ No newline at end of file diff --git a/results/scraper/fex/895 b/results/scraper/fex/895 new file mode 100644 index 000000000..15c4959f1 --- /dev/null +++ b/results/scraper/fex/895 @@ -0,0 +1,2 @@ +pselect6 is wrong +Final argument is incorrect. \ No newline at end of file diff --git a/results/scraper/fex/896 b/results/scraper/fex/896 new file mode 100644 index 000000000..76f03096e --- /dev/null +++ b/results/scraper/fex/896 @@ -0,0 +1,4 @@ +Guest applications that try allocating an executable stack fail to set permissions +Seems like the mprotect fails for whatever reason. +Life is Strange's launcher hits this very early and crashes out. +Seems to come from libCoreFoundation \ No newline at end of file diff --git a/results/scraper/fex/897 b/results/scraper/fex/897 new file mode 100644 index 000000000..97593c931 --- /dev/null +++ b/results/scraper/fex/897 @@ -0,0 +1,8 @@ +On ARMv8.4 LSE2 supporting devices remove padding on atomic loadstore +ARMv8.4 LSE2 allows atomics to be unaligned which means we no longer need to proactively backpatch these. +We still need to handle the cross-cacheline case. + +Three steps to this. +* Add two new atomic handlers in the signal handler for atomic loads and stores that cross cacheline +* Remove the padding on the TSO loadstores when LSE2 is supported +* Add unit tests for missing atomic loadstore ops that cross cacheline (We already have it for memory atomic ops) \ No newline at end of file diff --git a/results/scraper/fex/898 b/results/scraper/fex/898 new file mode 100644 index 000000000..1c10d0c84 --- /dev/null +++ b/results/scraper/fex/898 @@ -0,0 +1,2 @@ +Change FEX symbols to be default invisible +Requires marking up the few things we actually want to expose. \ No newline at end of file diff --git a/results/scraper/fex/899 b/results/scraper/fex/899 new file mode 100644 index 000000000..a611a1633 --- /dev/null +++ b/results/scraper/fex/899 @@ -0,0 +1,2 @@ +Stop compiling libFEXCore twice +Compile it statically then use that to generate the shared library. \ No newline at end of file diff --git a/results/scraper/fex/90 b/results/scraper/fex/90 new file mode 100644 index 000000000..f84945c06 --- /dev/null +++ b/results/scraper/fex/90 @@ -0,0 +1,2 @@ +Look in to guest faulting and guest signal support +This is gonna be an aspect that we need to support. \ No newline at end of file diff --git a/results/scraper/fex/900 b/results/scraper/fex/900 new file mode 100644 index 000000000..223b14fe6 --- /dev/null +++ b/results/scraper/fex/900 @@ -0,0 +1,3 @@ +Add option to enable logging in FEXLoader and TestHarnessRunner +Oops, disabled this. +CI artifacts are worthless now \ No newline at end of file diff --git a/results/scraper/fex/901 b/results/scraper/fex/901 new file mode 100644 index 000000000..92b932c3e --- /dev/null +++ b/results/scraper/fex/901 @@ -0,0 +1 @@ +Create man file diff --git a/results/scraper/fex/906 b/results/scraper/fex/906 new file mode 100644 index 000000000..29d0438eb --- /dev/null +++ b/results/scraper/fex/906 @@ -0,0 +1,5 @@ +Switch FEXConfig from GLFW to SDL +GLFW will consume 100% of a CPU core in some instances. +For details: https://github.com/glfw/glfw/issues/1872 + +Switch to SDL window creation instead. Can't work around the GLFW bug from the application side. \ No newline at end of file diff --git a/results/scraper/fex/908 b/results/scraper/fex/908 new file mode 100644 index 000000000..d05c34ffe --- /dev/null +++ b/results/scraper/fex/908 @@ -0,0 +1,4 @@ +ELF loading cleanups +Move ELF code loading to the frontend instead of FEXCore. +Clean up the interface to communicate with it. +Remove the Dynamic loader bits of it. \ No newline at end of file diff --git a/results/scraper/fex/909 b/results/scraper/fex/909 new file mode 100644 index 000000000..f430774c7 --- /dev/null +++ b/results/scraper/fex/909 @@ -0,0 +1,4 @@ +Project short documentation in files +Cpp and header files having a parseable comment in the top. +Have a python script that searches all cpp and header file extensions and tries pulling out this parse text. +Generate a markdown file at the end as a cmake build step from python. \ No newline at end of file diff --git a/results/scraper/fex/925 b/results/scraper/fex/925 new file mode 100644 index 000000000..f811e9118 --- /dev/null +++ b/results/scraper/fex/925 @@ -0,0 +1,4 @@ +Switch our threading over to pthreads to fix misbehaving threads. +Civ6 needs this. +Also various other bugs occur because of std::thread and pthread desync. +We can think about the idea of switching to raw clone later. diff --git a/results/scraper/fex/927 b/results/scraper/fex/927 new file mode 100644 index 000000000..1fd558ff9 --- /dev/null +++ b/results/scraper/fex/927 @@ -0,0 +1,2 @@ +Stellaris Paradox launcher doesn't work at all +chrome sandbox quirks. \ No newline at end of file diff --git a/results/scraper/fex/929 b/results/scraper/fex/929 new file mode 100644 index 000000000..086040933 --- /dev/null +++ b/results/scraper/fex/929 @@ -0,0 +1,5 @@ +INTO implementation +FEX has an INTO implementation but it was disabled when we found out that it was 32-bit x86 instruction. +Now that we are supporting 32-bit x86 we should implement a unit test for this and wire it to the dispatcher tables. + +Might only be a partial unit test since we can't catch or generate synchronous signals yet. There is another issue about supporting that. \ No newline at end of file diff --git a/results/scraper/fex/93 b/results/scraper/fex/93 new file mode 100644 index 000000000..144376c12 --- /dev/null +++ b/results/scraper/fex/93 @@ -0,0 +1,4 @@ +Refactor everything to agnostic of CPUState structure layout +Currently, a lot of code implicitly depends on CPUState layout. Assumptions are smeared throughout the codebase. + +It would be nice to allow the layout of CPUState to be changed from a single place. \ No newline at end of file diff --git a/results/scraper/fex/930 b/results/scraper/fex/930 new file mode 100644 index 000000000..9d56423b4 --- /dev/null +++ b/results/scraper/fex/930 @@ -0,0 +1,4 @@ +binfmt_misc switch to POCF flags +We are currently CF only. +P and O add additional niceties that we want. +O specifically can let us early redirect uses of /proc/self/exe which is nice. \ No newline at end of file diff --git a/results/scraper/fex/931 b/results/scraper/fex/931 new file mode 100644 index 000000000..d410bb937 --- /dev/null +++ b/results/scraper/fex/931 @@ -0,0 +1,4 @@ +Shapez.IO electron container execve /proc/self/exe +We miss this redirect. +We should early redirect what /proc/self/exe is so this just works. +#930 might be helpful here. \ No newline at end of file diff --git a/results/scraper/fex/932 b/results/scraper/fex/932 new file mode 100644 index 000000000..9cc063828 --- /dev/null +++ b/results/scraper/fex/932 @@ -0,0 +1,2 @@ +Scourgebringer crashes in its bash shell +Haven't investigated why it crashes, just that it happens inside of its bash script when launched. \ No newline at end of file diff --git a/results/scraper/fex/934 b/results/scraper/fex/934 new file mode 100644 index 000000000..23081b94f --- /dev/null +++ b/results/scraper/fex/934 @@ -0,0 +1,2 @@ +Change default visibility to hidden +We expose too many symbols. Change everything to hidden \ No newline at end of file diff --git a/results/scraper/fex/935 b/results/scraper/fex/935 new file mode 100644 index 000000000..acc7a637a --- /dev/null +++ b/results/scraper/fex/935 @@ -0,0 +1,2 @@ +AppImage support? +Slipstream is an AppImage game. Why doesn't it work? \ No newline at end of file diff --git a/results/scraper/fex/94 b/results/scraper/fex/94 new file mode 100644 index 000000000..48eb2cdef --- /dev/null +++ b/results/scraper/fex/94 @@ -0,0 +1,7 @@ +skmp's TODO +- [x] Implement block lookups to not be hacky / aliasy +- [x] Syscall unit tests #116 +- [x] Look into signals / marshaling -> at least for segfaults with host context #90 +-- Write some test cases, exit on loops, etc +- [x] Cleanup the op dispatcher #26 +- [x] Build chroot image without x87 love \ No newline at end of file diff --git a/results/scraper/fex/955 b/results/scraper/fex/955 new file mode 100644 index 000000000..c98ee4d9b --- /dev/null +++ b/results/scraper/fex/955 @@ -0,0 +1,3 @@ +Investigate failing POSIX tests +We have a fairly large list of failing or disabled posix tests in CI. +We should go through the list and inspect why they are failing rather than blanket removing the bad actors. \ No newline at end of file diff --git a/results/scraper/fex/957 b/results/scraper/fex/957 new file mode 100644 index 000000000..e6558034e --- /dev/null +++ b/results/scraper/fex/957 @@ -0,0 +1,12 @@ +Factorio 1.1.30 crashes when loading +Factorio is crashing at around 95% when loading sounds, attaching a log file from Factorio. +I'm running FEX on a VirtualBox x64 VM running Ubuntu 20.04. +Used the newest FEX version at the time of writing this. +Factorio was downloaded from the game's website. +Chroot is also a base Ubuntu 20.04 rootfs with installed packages from the wiki. +Did not remove the specified files and folders as that causes a crash right at the start with some memory crash, attaching what I got out of GDB then. +[factorio-current.log](https://github.com/FEX-Emu/FEX/files/6260367/factorio-current.log) + + + + diff --git a/results/scraper/fex/962 b/results/scraper/fex/962 new file mode 100644 index 000000000..2cd798e82 --- /dev/null +++ b/results/scraper/fex/962 @@ -0,0 +1,2 @@ +Switch over to std::fs::path for our path handling +We use std::string in a bunch of the config locations. We should switch over to path. \ No newline at end of file diff --git a/results/scraper/fex/963 b/results/scraper/fex/963 new file mode 100644 index 000000000..4dbcbe7f4 --- /dev/null +++ b/results/scraper/fex/963 @@ -0,0 +1,3 @@ +Add Paranoid TSO mode +Shuffles vectors down the TSO mode using GPR<->FPR moves. +Stops backpatching code and adding fences around ops, handle misaligned ops in fault handler. \ No newline at end of file diff --git a/results/scraper/fex/966 b/results/scraper/fex/966 new file mode 100644 index 000000000..5a9cce55b --- /dev/null +++ b/results/scraper/fex/966 @@ -0,0 +1,4 @@ +Convert from CMake to Meson +It has real support for cross-compiling with host native tooling. Meaning we don't need to mess around with ExternalProject shenanigans. + +This will be fairly laborious so it's low priority. \ No newline at end of file diff --git a/results/scraper/fex/974 b/results/scraper/fex/974 new file mode 100644 index 000000000..309120a65 --- /dev/null +++ b/results/scraper/fex/974 @@ -0,0 +1,2 @@ +Change default logging location to stderr +Instead of stdout, use stderr by default to reduce problems that it can cause. \ No newline at end of file diff --git a/results/scraper/fex/979 b/results/scraper/fex/979 new file mode 100644 index 000000000..6909aa476 --- /dev/null +++ b/results/scraper/fex/979 @@ -0,0 +1 @@ +Get stats on 128bit Multiply and how often it can get optimized in basic application diff --git a/results/scraper/fex/980 b/results/scraper/fex/980 new file mode 100644 index 000000000..08b83ea7e --- /dev/null +++ b/results/scraper/fex/980 @@ -0,0 +1 @@ +Get stats on 128bit divide and how often it can get optimized in basic application diff --git a/results/scraper/fex/982 b/results/scraper/fex/982 new file mode 100644 index 000000000..108d18836 --- /dev/null +++ b/results/scraper/fex/982 @@ -0,0 +1,2 @@ +Optimize the Optimization passes +1.5%-2.5% time spent running in an optimization pass Means we should throw everything in the the world in to const prop. \ No newline at end of file diff --git a/results/scraper/fex/995 b/results/scraper/fex/995 new file mode 100644 index 000000000..bcd3809b6 --- /dev/null +++ b/results/scraper/fex/995 @@ -0,0 +1,3 @@ +Convert struct verifier over to C++ +The python implementation is too slow and as we extend to testing more 32-bit types it is just spending more time running. +Convert this to C++ so that it takes less than a minute to run in CI \ No newline at end of file diff --git a/results/scraper/fex/997 b/results/scraper/fex/997 new file mode 100644 index 000000000..3ceb90666 --- /dev/null +++ b/results/scraper/fex/997 @@ -0,0 +1,20 @@ +Issue building on Manjaro Arm64 +Hey there, was trying to build this on Manjaro Arm64 but ran into this issue + +``` +[corey@corey-pi4 Build]$ CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DENABLE_LTO=True -DBUILD_TESTS=False -G Ninja .. +-- Checking for module 'libxxhash>=0.7.3' +-- Package dependency requirement 'libxxhash >= 0.7.3' could not be satisfied. +Package 'libxxhash' has version '', required version is '>= 0.7.3' +CMake Error at /usr/share/cmake-3.20/Modules/FindPkgConfig.cmake:556 (message): + A required package was not found +Call Stack (most recent call first): + /usr/share/cmake-3.20/Modules/FindPkgConfig.cmake:778 (_pkg_check_modules_internal) + CMakeLists.txt:108 (pkg_check_modules) + + +-- Configuring incomplete, errors occurred! +See also "/run/media/corey/47F22DEE70C10570/projects/FEX/Build/CMakeFiles/CMakeOutput.log". +``` + +I installed xxhash but it still thinks it's missing. \ No newline at end of file diff --git a/results/scraper/fex/documentation/1202 b/results/scraper/fex/documentation/1202 new file mode 100644 index 000000000..61ab04dba --- /dev/null +++ b/results/scraper/fex/documentation/1202 @@ -0,0 +1,45 @@ +pressure-vessel upstream requirements +FEX needs some features in pressure-vessel in order to work correctly. +This is because pressure-vessel messes with the real filesystem which means that FEX can't transparently hide all aspects of this. + +- pressure-vessel needs to check if running in a FEX environment. + - Check CPUID for the CPU modelname for FEX `model name : FEX-2108-21-ge90892a2` + - Format is `FEX-<YYMM[.<Minor rev>]>[-<Commits since last tag>-<CurrentCommit>]` + - eg: Released Tag `FEX-2108` + - eg: Released Tag with minor rev `FEX-2108.1` + - eg: Commit that isn't in a release, aka building from origin/main `FEX-2108-21-ge90892a2` + - eg: Future release `FEX-2109` + - Minor revisions haven't occured in FEX yet + - Always separated by dashes. + - `FEX-<YYMM>` will always exist, the rest are optional. +- Once determined to be in a FEX environment, use the `FEXGetConfig` tool to find the currently configured rootfs + - PR #1204 Adds this configuration program. + - Exists since `FEX-2109` tagged revision + - `FEXGetConfig --current-rootfs` Returning the mounted rootfs location in the case of squashfs + - Or folder that the rootfs lives at if not squashfs + - `FEXGetConfig --current-rootfs-lock` To return the `lock` file to keep rootfs active. + - Necessary for new FEX instances to find the squashfs mount + - Will be in `/tmp/` + - `FEXGetConfig --current-rootfs-socket` To return the current UNIX domain socket for pipes watching + - Necessary to keep the FEXMountDaemon active while it tracks FEX instances + - Will be in `/tmp/` + - Only exists beggining at `FEX-2109-<X>` + - `FEXGetConfig --install-prefix` Will let you find where the FEX libraries are installed. Not everyone wants to install to /usr + - Optional `--app <Filename>` to get app profile configuration as well + - Usually not necessary, but future proofing will let us use this + - `FEXGetConfig --version` - Returns the same string as CPUID + - Aren't guaranteed to be running in a FEX environment without still checking CPUID. Be careful of that. + - Pressure-vessel should pull in $ROOTFS/usr/lib64 and $ROOTFS/usr/lib32 instead of true host folders + - Necessary since FEX may mount the rootfs in /tmp as squashfs or exist in ~/.fex-emu/RootFS or anywhere else + - Real host will not have any x86-64 or x86 libraries in the host root + - Also pull in $prefix/share/fex-emu/ and $prefix/lib/fex-emu/ + - Necessary for thunk support + - Also need /lib/aarch64-linux-gnu/ for thunks + - $ROOTFS/etc? + - I'm not sure if this matters. + - Pull in $prefix/FEXInterpreter for executing without binfmt_misc installed + - This can happen when testing on both an x86-64 and aarch64 host + - Since this is a hardlink to FEXLoader, special care might need to be taken? Not sure if a symlink to a hardlink exposes the original path or not. +- Once in the chroot. Set `FEX_ROOTFS=''` since the new root is a true x86 environment. + - This will override the rootfs that FEX is using to nothing. Necessary otherwise some things break. + - pressure-vessel configures its rootfs in a functional way that this works. \ No newline at end of file diff --git a/results/scraper/fex/documentation/145 b/results/scraper/fex/documentation/145 new file mode 100644 index 000000000..41bdf3591 --- /dev/null +++ b/results/scraper/fex/documentation/145 @@ -0,0 +1,15 @@ +FEX-EMU infrastructure +We have +- [fex-emu.org](fex-emu.org) +- [Google Calendar](https://calendar.google.com/calendar?cid=MWtyZTFtYzZzZnJwYm4zM2YyajQxdHFrdWNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ) +- [Google Drive Share (RO)](https://drive.google.com/open?id=1tWQbqYd4lJH54VVnMWaSAoEyP_ac0_Sa) +- email forwards for skmp, phire, hdkr @fex-emu.org +- [chat.fex-emu.org redirect](https://chat.fex-emu.org) + +We need +- Bot that auto merges PRs approved / made by @FEX-Emu/maintainers +- A non hello world website (See https://github.com/FEX-Emu/fex-emu.org/issues/1) + +In the future +- Register our trademark/namemark (@skmp can look into pricing in greece for worldwide, so we have an idea of the costs involved) +- a formal entity to represent us (@phire suggested looking into the NZ options to do this, so we have an idea of the costs and complexity involved) \ No newline at end of file diff --git a/results/scraper/fex/documentation/1682 b/results/scraper/fex/documentation/1682 new file mode 100644 index 000000000..e2e345cdc --- /dev/null +++ b/results/scraper/fex/documentation/1682 @@ -0,0 +1,61 @@ +Signal Handling +Splitting from #1558 & #1677, as well as discussions with @neobrain and @Sonicadvance1. + +## The issues +(a) Signals can interrupt the JIT compiler or syscall, other FEX-related code, 3rd party libraries, or thunked libraries, which are not guaranteed to be signal re-entrant safe. Any code that touches non-stack memory, or uses mutexes is possibly not signal safe. We currently block signals around some code, either using `ScopedSignalMaskWith*` guards or manually (eg, the dispatcher disabling signal handling around calls to CompileCode) + +(b) Signals can interrupt the translated code in the middle of operations that would normally be atomic wrt signals. This may or may not be a problem, depending on how we have implemented x86. A good example is REP* operations. This can be an issue even without LSE elimination, as the recovered guest state might be "teared". + +(c) Similar to above, signals can interrupt the translated code in places where we can't recover the guest architectural place, due to optimisations. + +(d) Similar to above, synchronous signals might be generated which need to recover a full context and cannot be deffered. + +Group 1: From x86 instructions +- SIGSEGV (memops, permissions / unmapped memory) +- SIGBUS (meops, mapping past end of file) +- SIGFPE (all floating point exceptions? Integer overflow too?) + +Group 2: Handled from the x86 frontend +- SIGILL (not handled instruction) +- SIGTRAP (breakpoint, `int3` or `int 0x3` +- SIGEMT (not generated) + +Group 3: Generated from system calls +- SIGSYS (Bad system call, SVr4; seccomp) +- SIGABRT (raise / __pthread_kill / kill others?) + +(e) Signal latency. Whenever we disable the signal mask, like we do around `::CompileCode`, or with the signal + mutex lock guards, signal delivery gets delayed. This is mostly a concern for long-standing/non constant time signal blocking, like around `::CompileCode` (can take up to 10+ miliseconds with complex blocks). There is an argument to be made that we should compile blocks faster, though that will never 100% solve the issue. Also, signal handlers can be delayed while code for them is getting compiled, particularly during their first run. + +(f) With deferred signals the opposite problem also appears, that we consume the signal too fast. I'm not sure if this results to an extra signal being possibly queued while a signal is deferred. Also, the signal might appear 'dequeued' to the sender, while it is still 'pending' in FEX, which might lead to some guest instructions running (a bit of 'execution overshoot'), a condition that can be detected, but extremely unlikely to matter to the guest. + +(g) While signal delivery is not guaranteed to happen at any speed, lovely features like signal queue merging, which can lead to losing information about the delivered signals, can uncover bugs / assumptions done in the guest code. + +## Current status +Our current "signal safety strategy" for (a) is to sprinkle signal disabling code around regions that deadlock. This is very inconsistent throughput the codebase, and there are several bugs waiting to be hit. In general, this is a compromise between "likely to lockup" and "performant code". + +For (b) and (c) we currently only partially recover the guest architectural state, store it alongside the host architectural state, and hope the guest code doesn't care too much about the contents of the guest state, and that it will not modify it. We depend on returning to the interrupted host code using the stored host architectural state, in order to resume execution in the middle of any teared instructions, and eventually exit from some point with a valid guest state. This poses another limitation, that the interrupted block cannot be discarded from the code cache, so the code cache cannot be cleared. This might also have further implications around SMC and code invalidations. + +## Proposed solutions +For (a) I'd like us to have clear guidelines on how to handle this, as well as a mode that might be slower but offers guaranteed stability. This needs some thought, but is not too hard. + +For (b) and (c) the only viable solution I can think of is a combination of deferring the signal delivery until we have a fully recoverable guest state, and storing metadata that can help us exit from the middle of a block. (c) Can be avoided by limiting store elimination from LSE and disabling DSE. We can have a tradeoff between "defer delay" vs "runtime performance". + +For (d.1), we'll need special state flushing semantics and/or recovery metadata and/or exit blocks in instructions that may cause them. This requires extra caution around SRA. + +For (d.2), the frontend can take care of everything. + +For (d.3), we can likely merge it with the syscall handling case of (a) + +For (e) we can implement some form of 'aborts' for long running cases with blocked signals, ie early exits during `::CompileCode` or even possible `conditional aborts` ie temporarily pausing the execution but only aborting if re-executed before getting resumed. + +For (f), we can modify the behavior syscalls where signal queueing status can be detected, and make them take actual signal delivery by FEX to the guest into account. This cannot be perfect during guest/host process interop. + +For (g), we can implement 'user mode queueing', possibly on top of (g), to get closer to native guest behaviour. + +(e) + (f) + (g) are edge case behaviors that is unlikely to matter in practice, and can mostly get triggered by compilation stutter completely altering the expected timing of the guest application. + +## Related Tickets +#518, #650, #1228, #1666 + +## Other information +Unity depends on at least graceful handling of asynchronous SIGPWR, SIGXCPU (GC, loose context requirements) and SIGSEGV w/ null pointers (NullReferenceException generation, strict context requirements). diff --git a/results/scraper/fex/documentation/1697 b/results/scraper/fex/documentation/1697 new file mode 100644 index 000000000..8c12e8e00 --- /dev/null +++ b/results/scraper/fex/documentation/1697 @@ -0,0 +1,26 @@ +Fork safety +We need to guarantee that forks under fex are not more unsafe than forks of the native program itself. + +In theory, multithreaded programs are not supposed to fork. In practice, it happens quite often. + +Compilations: + +### Deadlocks + +If a thread other than the one doing the owns has any kind of lock, then that lock will never be unlocked in the forked program. Also, some locks may not gracefully handle forks (see: #1681). These issues also extend to any libraries FEX uses, including c/c++ runtimes, jemalloc, and others. + +A partial solution to this is for the forking thread to own all the locks before fork, and for us to use custom lock implementations that are guaranteed to work across forks. + +Currently, this is only done for the `FileManager` mutex. #1558 adds a generic place to do this for the syscalls handlers, and we need to go over all our os/frontend mutexes and add them there. + +FEXCore itself doesn't have a callback for forks yet, that needs to be looked as well. + +This could also be solved semi-automatically if we keep a list of all locks, possibly as part of our own custom lock type, though we need some way to define locking interdependencies and also interop with foreign lock types. + +This is written with mutexes in mind, but it applies to all synchronization primitives, possibly including condvars, futexes, atomics, etc. + +### Memory Leaks + +When a thread forks, we need to drop all memory used by other threads. I haven't investigated to what extent that is done, and a possible efficient mechanism might be per thread memory pools with `madvise(MADV_DONTFORK)` and/or de-allocation callbacks to be called post-fork. + +@phire worked on this previously, #889 contains some more information. \ No newline at end of file diff --git a/results/scraper/fex/documentation/1746 b/results/scraper/fex/documentation/1746 new file mode 100644 index 000000000..6d22aa418 --- /dev/null +++ b/results/scraper/fex/documentation/1746 @@ -0,0 +1,13 @@ +Self Modifying Code (SMC) Support +#### Overview +X86 has fully coherent icache, and in some models, prefetch queue and OoO buffers are also coherent (citation needed, unit test pending). + +This means that in order to be fully correct we need to detect code changes when they happen, execute only new code after the write completes, across all threads, and that no thread should observe any other thread running stale code. + +FEX currently supports 4 modes of SMC +- No support +- Mman (Invalidation around mmap, munmap, etc apis) +- Mtrack (Mman + segfault based detection of changes) +- Full (Disables most cross-block optimisations, checks every instruction for modification before executing it) + +(@skmp todo: fill with more information about what actually is supported, next tasks, related tickets, etc) \ No newline at end of file diff --git a/results/scraper/fex/documentation/1890 b/results/scraper/fex/documentation/1890 new file mode 100644 index 000000000..d76590dbb --- /dev/null +++ b/results/scraper/fex/documentation/1890 @@ -0,0 +1,35 @@ +Documentation Home +## Quick Links +- [Code Of Conduct](https://github.com/FEX-Emu/FEX/blob/main/CODE_OF_CONDUCT.md) +--- +- [Next Project Milestone](https://github.com/orgs/FEX-Emu/projects/4/views/1) +--- +- [Release & Milestones](https://github.com/FEX-Emu/FEX/milestones?direction=asc&sort=due_date&state=open) +- [Unstaged Tickets](https://github.com/FEX-Emu/FEX/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone+-label%3Augc+-label%3Adocumentation+-label%3Adiscussion+-label%3Aproposal) +- [Code Review for Merges](https://github.com/FEX-Emu/FEX/pulls?q=is%3Apr+is%3Aopen+-is%3Adraft) +- [Code Review for Proposals](https://github.com/FEX-Emu/FEX/pulls?q=is%3Apr+is%3Aopen+is%3Adraft) +--- +- [Read Me](https://github.com/FEX-Emu/FEX/blob/main/README.md) + +## Get In Touch +- [Instant Messaging](https://discord.gg/fexemu) +- [Discussion Forum](https://github.com/FEX-Emu/FEX/discussions) + +## Contributing +- CONTRIBUTING.MD (TBD) +- [Release & Milestone Planning](https://github.com/FEX-Emu/FEX/milestones?direction=asc&sort=due_date&state=open) + +## High Level View +- Signal Handling: #1682 +- Self Modifying Code: #1746 +- Fork Safety: #1697 +- AOT & IR Caching: #828 (wayy outdated) +- neobrain's thunking planning: https://github.com/neobrain/FEX/projects/1 + +## Code Structure +- [Source Outline](https://github.com/FEX-Emu/FEX/blob/main/docs/SourceOutline.md) + +## Infrastructure +- Infa: #145 + + diff --git a/results/scraper/fex/documentation/1908 b/results/scraper/fex/documentation/1908 new file mode 100644 index 000000000..bfd8c6c2e --- /dev/null +++ b/results/scraper/fex/documentation/1908 @@ -0,0 +1,34 @@ +Security Model and Implications +#### Overview +FEX may have a weaker security model vs typical posix. + +Namely, IR or OBJ cache assume that every FEX process is a trusted peer. + +As FEX shares address spaces and security tokens with the emulated application, there's no way to guarantee that a malicious application can't modify the behaviour of any other FEX process, as long as they share caches. + +This is even more important around setuid binaries that operate in a separate security context. As is execution of setuid executable through FEX could lead to privileged data leakage and privilege escalation. + +I have a mental note to tackle these issues as part of [2212](https://github.com/FEX-Emu/FEX/milestone/3), I will budget some time to create tickets and further document the situation latest during [2210](https://github.com/FEX-Emu/FEX/milestone/1). + +Also note that the FEX VM and IR don't offer any correctness or security guarantees right now. + +#### Brain Dump + +Sadly, linux has very limited support for in place context switching (only vfork), so zero/low cost security contexts are not an option. Maybe vfork is enough. + +Sadly, linux has only one granularity of page protection, no ASIDs, and in general the memory management api and infrastructure is extremely poor. + +Sadly, linux also has almost no apis for information management / data and metadata leakage mitigation (only madvise and very few options there iirc). + +#### What can we do + +##### For privilege and data protection +- Make cache management happen under a different uid, and ask a fexserver to compile. Complications: Linux induced overhead. +- Try to escalate a task during compilation via vfork: Complications vfork overhead,, questions of forked process privileges. +- Try to restrict the guest from accessing the FEX structures (48th address bit in aarch64 running x86_64, 32th+ bits in any running x86_32, segment registers in x86) +- Use caches in readonly mode + AOT +- ? + +#### For metadata protection +- AOT +- ? \ No newline at end of file diff --git a/results/scraper/fex/documentation/1914 b/results/scraper/fex/documentation/1914 new file mode 100644 index 000000000..8d85ec4f8 --- /dev/null +++ b/results/scraper/fex/documentation/1914 @@ -0,0 +1,18 @@ +Address Space Stealing +As part of #1885 a few ideas turned up + +We want to steal the address space first thing, before libc's _start, and also before the dynamic linker. + +Current ideas on how to get there +- Make a custom ld-linux replacement, ld-stealmem +- ld-stealmem should steal the address space (example: https://github.com/FEX-Emu/fex-assorted-tests-bins/blob/main/address-space-stealing/alloc.cpp) +- Implement our own mmap, munmap and put them in a section +- Use seccomp-bpf (test: https://github.com/FEX-Emu/fex-assorted-tests-bins/blob/main/seccomp/secccomp.c) to redirect to our internal mmap, munmap if the syscall doesn't come from our special section. Verified to work on x86_64 (ubuntu 22.04) and arm64 (ubuntu 20.04) +- Possibly make a virtual mmap flag to control host/guest mmaps +- Load the real ld-linux via our ELF loader (example: https://github.com/FEX-Emu/FEX/blob/main/Source/Tests/ELFCodeLoader2.h#L104) +- Modify the AT_ENTRYPOINT & friends 'as if' ld-linux was launched by the kernel +- destroy the stack frame and jump to ld-loader, which will load FEX +- (maybe for each thread?) make a je_malloc arena that is host-prefered +- provide host_malloc & friends + +We can also define virtual syscalls, or extend prctl to control `ld-stealmem` better \ No newline at end of file diff --git a/results/scraper/fex/documentation/828 b/results/scraper/fex/documentation/828 new file mode 100644 index 000000000..22e6ef7ae --- /dev/null +++ b/results/scraper/fex/documentation/828 @@ -0,0 +1,28 @@ +AOT & IR Cache Planning +This is a high level ticket, to track the work that needs to be done for a fairly complete aot/ir cache setup. Follow up from #47 #693 + +## Current state +- FEXLoader can capture IR to aot files via `--aotircapture` +- FEXLoader can load IR from aot files via `--aotirload` +- FEXLoader can pre-process an entire elf with `--aotirgenerate` +- IR loading is done per executable file (.so or otherwise) +- IR loading depends on mmap hooks to detect when binaries are loaded +- IR is loaded via mmap w/ index +- Used modules create a .path entry in ~/.fex-emu/aotir/ +- Scripts/FEXUpdateAOTIRCache.sh reads .path files and generates .aotir files for the matching elfs/so files + +### Multi threaded AOTIR generation +- There's a POC branch, needs multiple thread contexts and some other tweaks + +### Streamable AOTIR generation +- Move the index to the end of the file +- Stream writes + +### Precompiled binary caching (~ 2-4 weeks to reviewable code) +- Needs our jit to be relocation-aware +- Needs our codegen to be relocation-optimized +- Needs similar logic to mmap-based ir loading for the metadata +- Needs relocation information to be stored and parsed and applied + - Preferably on a per-block use basis, to avoid stutters in large files +- Should introduce a FEXAOTCompiler to compile IR caches to binary caches +- Should introduce a new cache loading mode, `--aotbin-load` or such that loads binary caches \ No newline at end of file |