mirror of
https://github.com/ARMSX2/ARMSX3.git
synced 2026-08-24 16:58:52 -07:00
jpolo1224
43df8b0dc2
The core is built for armv8.1-a and that is a floor, not a preference: util/simd.hpp emits SQRDMLAH and util/asm.hpp carries inline LSE atomics. On ARMv8.0 silicon -- Cortex-A53/A57/A73, so Exynos 9610, Snapdragon 660 and the like -- those are illegal opcodes. What the user saw was a bare crash. The fault is a SIGILL inside a static constructor while the linker is still running libarmsx3-core.so's initialisers, so it happens before any of our code can report anything, and the top frame names a log-channel registration rather than a CPU problem. Because the core is dlopen'd lazily, it surfaced at whatever first needed it -- issue #15 filed it as "crashes when selecting the firmware .pup file", which is where the crash appears and not what it is about. Check /proc/cpuinfo for atomics and asimdrdm before that dlopen and report it. Checked across every core listed, not just the first, since emulator threads are scheduled on all of them. Fails OPEN by design: an unreadable or unfamiliar /proc/cpuinfo returns null and loads as before. Blocking a device that would have worked is worse than the crash this replaces. Verified on a Snapdragon 8 Gen 2 that all eight cores report both flags, so nothing changes there. The reason is also held in unsupportedCpuMessage so a screen can show it later; a toast is easy to miss for something this final.