Follow-up to #3976 (the system() / binfmt question - thank you again, that answer unblocked me completely). This is a progress update with two findings from real Snapdragon 8 Gen 2 hardware that might be useful, plus one question at the end. Not a bug report I'm expecting you to action - more flagging what I'm seeing in case it's helpful.
Since #3976 I've been launching the game directly through box64 (so box64 wraps it and the system() path never comes into it), using the original lindbergh-loader v2.1.4. The game now loads fully and runs under Box32. Two distinct Box32 stack-corruption faults remain, and the interesting part is that no single box64 version currently clears both.
Setup (unchanged from #3976): Retroid Pocket 6, Snapdragon 8 Gen 2, arm64, Android 13, no root, Termux + proot Debian Trixie. box64 built from source with BOX32 and -DSD8G2=ON. Rendering via Turnip + Zink.
1. A Box32 regression on a libxdiff code path, between February main and current main
The loader does binary-diff shader patching using a statically-linked libxdiff inside its hook library (lindbergh.so).
Current main (commit 8e661d2, 2026-06-25) stack-corrupts very early, inside libxdiff:
[BOX32] 0x40062648: Stack is corrupted, aborting ESP=0x3081e420 lindbergh.so/xdl_bogosqrt
It loops in the loader's own SIGSEGV handler (millions of times in ~15s) and never reaches SDL. xdl_bogosqrt is libxdiff's integer sqrt, called from its diff routine during the patching.
v0.4.3, and a later February main build (commit 05b1086, 2026-02-24), both execute that exact libxdiff path cleanly and proceed to SDL.
So something between 05b1086 and current HEAD (559 commits) looks like it regressed Box32 on this path. It's identical with BOX64_DYNAREC=0, so it doesn't appear to be a recompiler codegen issue - it reproduces in the interpreter too. GPU vendor selection (which only changes which shader data gets patched) makes no difference either.
2. Emulated i386 SDL3 SDL_Init(SDL_INIT_VIDEO) stack-corrupts, and the native wrapper is 64-bit only
On any build that clears #1 (v0.4.3 and 05b1086), the game reaches SDL3 and then stack-corrupts in the emulated i386 libSDL3 during video init:
[BOX32] 0x403e0008: Stack is corrupted, aborting ESP=0x3080eee8 .../libSDL3.so.0 + 0x1fa008
ERROR: SDL_GetCurrentDisplayMode Error: Video subsystem has not been initialized
(EIP 30822873.) Also identical with BOX64_DYNAREC=0, and identical across two different i386 SDL3 builds (system libSDL3 3.2.10 and the loader's bundled one).
I tried to route around this with the native SDL3 wrapper - made a native aarch64 libSDL3.so.0 fully loadable (all deps satisfied, ldd clean) and set BOX64_PREFER_WRAPPED=1. box64 still emulates the i386 copy. Looking at the source, wrappedsdl3.c is only registered for 64-bit (src/wrapped/); there's no 32-bit counterpart in src/wrapped32/ and no entry in library_list_32.h, and that's still the case on current HEAD. So Box32 has no native SDL3 to select and falls back to the emulated path that hits the crash above. (SDL2 has a 32-bit wrapper, so I assume SDL3 just hasn't been added on that side yet.)
That's what leads to my one question - and I want to be clear it's a question, not a request: would a 32-bit (wrapped32) SDL3 wrapper be feasible to add at some point? It would let Box32 titles like this bypass the emulated-SDL3 video-init crash entirely. Completely understand if it sits low on the list - I mostly wanted to flag that the wrapper gap is what forces the emulated path here, so it's clear the two findings are related.
I'm very happy to help from the hardware side: I can attach full BOX64_LOG=2 logs and the complete register/stack dumps for either fault, rebuild any commit or diagnostic patch you'd like tried, and report back from the actual SD8G2 device, which I appreciate isn't always easy to test against. Whatever's useful to you.
Thanks again for box64, and for the time on the last thread.
Follow-up to #3976 (the system() / binfmt question - thank you again, that answer unblocked me completely). This is a progress update with two findings from real Snapdragon 8 Gen 2 hardware that might be useful, plus one question at the end. Not a bug report I'm expecting you to action - more flagging what I'm seeing in case it's helpful.
Since #3976 I've been launching the game directly through box64 (so box64 wraps it and the system() path never comes into it), using the original lindbergh-loader v2.1.4. The game now loads fully and runs under Box32. Two distinct Box32 stack-corruption faults remain, and the interesting part is that no single box64 version currently clears both.
Setup (unchanged from #3976): Retroid Pocket 6, Snapdragon 8 Gen 2, arm64, Android 13, no root, Termux + proot Debian Trixie. box64 built from source with BOX32 and -DSD8G2=ON. Rendering via Turnip + Zink.
1. A Box32 regression on a libxdiff code path, between February main and current main
The loader does binary-diff shader patching using a statically-linked libxdiff inside its hook library (lindbergh.so).
Current main (commit 8e661d2, 2026-06-25) stack-corrupts very early, inside libxdiff:
[BOX32] 0x40062648: Stack is corrupted, aborting ESP=0x3081e420 lindbergh.so/xdl_bogosqrtIt loops in the loader's own SIGSEGV handler (millions of times in ~15s) and never reaches SDL. xdl_bogosqrt is libxdiff's integer sqrt, called from its diff routine during the patching.
v0.4.3, and a later February main build (commit 05b1086, 2026-02-24), both execute that exact libxdiff path cleanly and proceed to SDL.
So something between 05b1086 and current HEAD (559 commits) looks like it regressed Box32 on this path. It's identical with BOX64_DYNAREC=0, so it doesn't appear to be a recompiler codegen issue - it reproduces in the interpreter too. GPU vendor selection (which only changes which shader data gets patched) makes no difference either.
2. Emulated i386 SDL3 SDL_Init(SDL_INIT_VIDEO) stack-corrupts, and the native wrapper is 64-bit only
On any build that clears #1 (v0.4.3 and 05b1086), the game reaches SDL3 and then stack-corrupts in the emulated i386 libSDL3 during video init:
(EIP 30822873.) Also identical with BOX64_DYNAREC=0, and identical across two different i386 SDL3 builds (system libSDL3 3.2.10 and the loader's bundled one).
I tried to route around this with the native SDL3 wrapper - made a native aarch64 libSDL3.so.0 fully loadable (all deps satisfied, ldd clean) and set BOX64_PREFER_WRAPPED=1. box64 still emulates the i386 copy. Looking at the source, wrappedsdl3.c is only registered for 64-bit (src/wrapped/); there's no 32-bit counterpart in src/wrapped32/ and no entry in library_list_32.h, and that's still the case on current HEAD. So Box32 has no native SDL3 to select and falls back to the emulated path that hits the crash above. (SDL2 has a 32-bit wrapper, so I assume SDL3 just hasn't been added on that side yet.)
That's what leads to my one question - and I want to be clear it's a question, not a request: would a 32-bit (wrapped32) SDL3 wrapper be feasible to add at some point? It would let Box32 titles like this bypass the emulated-SDL3 video-init crash entirely. Completely understand if it sits low on the list - I mostly wanted to flag that the wrapper gap is what forces the emulated path here, so it's clear the two findings are related.
I'm very happy to help from the hardware side: I can attach full BOX64_LOG=2 logs and the complete register/stack dumps for either fault, rebuild any commit or diagnostic patch you'd like tried, and report back from the actual SD8G2 device, which I appreciate isn't always easy to test against. Whatever's useful to you.
Thanks again for box64, and for the time on the last thread.