GHCi broken on AArch64/Debian 11

Any attempt to load code in a statically-linked GHCi session on AArch64/Debian 11 is currently broken due to RtsSymbols.c not providing the __aarch64_ldadd1_acq_rel symbol, which was introduced for GCC's relatively-new out-of-line-atomics support:

=====> T5882(ext-interp) 1 of 1 [0, 0, 0]
cd "/tmp/ghctest-52fpvexp/test   spaces/testsuite/tests/th/T5882.run" &&  "/home/ghc/ghc/_build/stage1/bin/ghc" -c T5882.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -fno-dump-with-ways -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0< 
Compile failed (exit code 1) errors were:
ghc-iserv: Failed to lookup symbol: __aarch64_ldadd1_acq_rel

added ARM Pnormal Tbug linking labels

mentioned in merge request !8802 (closed)

mentioned in merge request !8790 (closed)

mentioned in issue #22005 (closed)

marked this issue as related to #22011

mentioned in issue #22011

changed milestone to %9.6.1

assigned to @bgamari

This issues gets more critical by the day @bgamari, but I bump it off until 9.8.1

changed milestone to %9.8.1

mentioned in issue #23482 (closed)

added Phigh label and removed Pnormal label

This is blocking #23482 (closed), I have marked it Phigh priority.

I think I know how to fix this, there are lots of related issues with pretty much all our cross compilers. But fixing it properly likely requires us to add some logic to GHC that accepts a -linker-preload flag, and then feeding those mentioned libraries into the linker first. (instead of having it all hardcoded in the rts). Otherwise we'll eventually ending up throwing most of the libc, and libgcc (or similar) symbols into the rts.

The solution I was planning g on implementing here was to probe libc for its exports and use this to dynamically generate RtsSymbols.

assigned to @AndreasK

@bgamari that seems quite similar! I would also have created (ideally dynamic), the RtsSymbols stub Lib and feed that in via -linker-preload. We can’t load all of libc, libgcc, … so we’d have to make do with some stub. Just outside of the rts itself ideally and dynamically changeable. (You can end up running into unknown symbols only when you compile some module that loads a c library, which uses some gcc/libc/… symbol the linker would provide by default).

I'm not sure we really want to make this runtime configurable. This is, afterall, only an issue of the toolchain.

I can also think of two other designs:

• Always link (weakly) against all possible toolchain-provided symbols. Only insert those symbols which are defined into the symbol table. This is simpler to implement but doesn't rid us of the requirement that we maintain this list.
• Simply add the out-of-line atomics builtins (of which __aarch64_ldadd1_acq_rel is one) to RtsSymbols and punt the problem down the road.

For 9.8, I think it would be best to do the latter.

@bgamari sure for 9.8 that sounds reasonable. In general I’m fairly certain we want some way to tell GHC to preload a library into the linker.

You often need these symbols only for the linker session. You don’t want them (all) in the RTS all the time. Even today the RTS_SYMBOLS is an annoying fragile hack.

if you could load libgcc, libc, libm, libatimic, rts, into the linker just fine (and this would likely only work for our static linker anyway), you could preload them always and have none of these symbol issues.

The problem is, we can’t. We can’t reinitialize values the libc expects to initialize only once (they are initiliazex when iserv starts up), same for other singleton state; it’s the same reason we can’t load the rts twice. For libgcc ther are even synthesized builtins, symbols that don’t exist anywhere but the compiler knows how to synthesize on demand.

I also do not think we can know or compute this completely at compile time.

So I do strongly believe we want to have a -linker-preload flag. And I also believe we want to separate out the rts symbols from the RTS and link them into some linker support library.

We’d likely also want to link the RTS_SYMBOLS only into the iserv/GHC executable, not into all rts libraries.

mentioned in commit 8d7ee087

mentioned in merge request !10814 (closed)

mentioned in commit c172be01

mentioned in commit d38c4752

Fixed in !10814 (closed).

mentioned in commit d8509abd

mentioned in commit 9d471794

mentioned in commit f71188cc

mentioned in commit 18c30684

mentioned in commit 1e26170a

Just to add to this, it doesn't seem to be limited to darwin, I'm seeing it on AArch64 Ubuntu.

mentioned in merge request !10846

mentioned in commit 542073cc

mentioned in commit 1ca2f799

mentioned in commit 9d234040

mentioned in merge request !11172 (closed)

mentioned in commit cd702c39

mentioned in commit 9a24e016

mentioned in commit 108479c8

mentioned in commit 941e85d5

mentioned in commit d636cf40

mentioned in commit ab659ad9

mentioned in commit 1b7f1cde

mentioned in commit 7876954f

mentioned in commit 8ed22662

mentioned in commit 75f5f4d8

mentioned in commit 5fa19487

mentioned in commit 2655e937