15 files changed, 652 insertions, 0 deletions
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