armv7a: dl_impl segfaults under qemu-arm during persistent-sqlite TH

[jappeace-sloth]

Problem

Cross-compiling for armv7a fails with a segfault in dl_impl.c when QEMU arm tries to evaluate Template Haskell in persistent-sqlite (makeCompatibleKeyInstances).

The iserv-proxy-interpreter crashes during symbol table initialization:

dl_impl: init_symtab called
dl_impl: g_nsyms = 0x1e41e
dl_impl: g_strsz = 0x7fb433
dl_impl: g_symtab = 0x1024c
dl_impl: g_strtab = 0x2e6524
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
iserv-proxy: {handle: <socket: 18>}: GHCi.Message.remoteCall: end of file

The failing TH splice is in Database/Persist/Sqlite.hs:

Code: makeCompatibleKeyInstances
        [t| forall b. Compatible b (RawSqlite b) |]

Reproduction

From prrrrrrrrr (or any consumer with persistent-sqlite as a cross-dep):

nix-build nix/android.nix --argstr androidArch armv7a

Analysis

• dl_impl initializes its symbol table from the static iserv-proxy-interpreter binary's ELF headers
• g_symtab = 0x1024c looks suspiciously low — possibly a file offset being used as a memory address, or the symbol table falls in an unmapped region under QEMU arm
• aarch64 builds work fine (CI passes), only armv7a is affected
• armv7a intentionally omits -pie (because "ARM32 CRT startup doesn't reliably relocate .dynsym entries in static PIE") — this non-PIE setup may interact poorly with how dl_impl reads the symbol table
• prrrrrrrrr CI never builds armv7a (apkArm7a is defined in ci.nix but not built), so this was never caught

Environment

• hatter pin: 226d46a (master, includes consumer TH support PR Support Template Haskell in consumer code (mkAndroidLib) #143)
• Also reproduces on older pin 35f3119 (hangs instead of crashing — same root cause, the iserv connection never establishes)
• nixpkgs: nixpkgs-unstable fdc7b8f7b30f
• GHC cross: 9.10.3
• persistent-sqlite: 2.13.3.1

🤖 Generated with Claude Code

[jappeace-sloth]

Investigation Results (armv7a TH segfault)

Extensive debugging of the armv7a TH cross-compilation segfault reveals the crash is in GHC's ARM32 RTS, not in our dl_impl.c code.

Crash Details

• PC = 0x1f9e34c — instruction in GHC's RTS .text (near libdw/IO manager functions)
• Fault address = 0xfffffffa — invalid pointer dereference (not a valid memory address)
• LR = 0x4144f06c — return address in RTS-loaded .o code (mmap'd region)
• SP = 0x407fa578 — normal stack

What Was Tried

All of these were tested locally with nix-build nix/ci.nix -A th-direct-test-armv7a:

Approach	Result
QEMU guest_base -B 0x10000000	Same crash
No guest_base (default)	Same crash
-pie flag (like aarch64)	Same crash
--wrap=mmap (mmap wrapper from aarch64)	Same crash
ARM EABI memory helpers (impl in dl_impl.c)	Same crash, earlier
ARM EABI memory helpers (extern weak to compiler-rt)	Same crash, earlier

Key Observations

1. The __aeabi_memcpy4 etc. symbols ARE in .dynsym (WEAK GLOBAL from compiler-rt), so dlsym does find them.
2. Adding code to dl_impl.c (even just a signal handler) changes the binary layout enough to make the crash happen on the first dlsym call instead of after many calls — but the root crash is the same (addr=0xfffffffa).
3. The crash is deterministic across builds.

Conclusion

This is a GHC ARM32 RTS issue under QEMU user-mode emulation. Possible root causes:

• ARM32-specific RTS initialization bug (DWARF/backtrace setup?)
• QEMU ARM32 emulation bug (specific instruction or memory model)
• Bionic static CRT interaction under QEMU

The test target (th-direct-test-armv7a) has been moved to knownFailing in ci.nix (PR #148) so it doesn't block CI. It's still buildable individually.