Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias, On Thu, 2024-06-13 at 20:50 +0200, John Paul Adrian Glaubitz wrote: > > Do we still have to build an unregisterised compiler for powerpc > > or can we switch back to NCG (https://bugs.debian.org/1060196)? > > I have not verified that yet. Please let's stay unregisterised for now > and have me verify first whether the NGC has been fixed with 9.6.x or > newer. > > Please let's keep this bug report open and use #1073159 [1] for adding > the flag --disable-ld-override to EXTRA_INSTALL_CONFIGURE_FLAGS. GHC 9.6.5 still fails on powerpc with the NGC enabled: # rts/include/rts/prof/LDV.h | Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => _build/stage1/rts/build/cmm/HeapStackCheck.debug_o | Run Ghc CompileHs Stage1: rts/PrimOps.cmm => _build/stage1/rts/build/cmm/PrimOps.p_o | Run Ghc CompileHs Stage1: rts/Updates.cmm => _build/stage1/rts/build/cmm/Updates.thr_p_o | Run Ghc CompileHs Stage1: rts/Compact.cmm => _build/stage1/rts/build/cmm/Compact.thr_p_o | Run Ghc CompileHs Stage1: rts/Exception.cmm => _build/stage1/rts/build/cmm/Exception.o | Run Ghc CompileHs Stage1: rts/PrimOps.cmm => _build/stage1/rts/build/cmm/PrimOps.debug_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.debug_p_o | Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => _build/stage1/rts/build/cmm/HeapStackCheck.p_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.thr_debug_p_o | Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => _build/stage1/rts/build/cmm/StgMiscClosures.debug_o | Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => _build/stage1/rts/build/cmm/StgMiscClosures.p_o | Run Ghc CompileHs Stage1: rts/ContinuationOps.cmm => _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o | Run Ghc CompileHs Stage1: rts/Updates.cmm => _build/stage1/rts/build/cmm/Updates.debug_p_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.thr_p_o | Run Ghc CompileHs Stage1: rts/Apply.cmm => _build/stage1/rts/build/cmm/Apply.o | Run Ghc CompileHs Stage1: rts/Exception.cmm => _build/stage1/rts/build/cmm/Exception.debug_o | Run Ghc CompileHs Stage1: rts/Apply.cmm => _build/stage1/rts/build/cmm/Apply.thr_dyn_o Command line: _build/stage0/bin/ghc -Wall -Wcompat -hisuf debug_p_hi -osuf debug_p_o -hcsuf debug_p_hc -static -prof -DDEBUG -optc-DDEBUG -hide-all-packages -no-user-package-db '-package-env -' '- package-db _build/stage1/inplace/package.conf.d' '-this-unit-id rts-1.0.2' -i -i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/rts/build -i/home/glaubitz/ghc-deb-9.6.5-new/ghc- 9.6.5/_build/stage1/rts/build/autogen -i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/rts -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -I_build/stage1/rts/build/@FFIIncludeDir@ -I_build/stage1/rts/build/@LibdwIncludeDir@ -Irts/include -Irts/@FFIIncludeDir@ -Irts/@LibdwIncludeDir@ -optP-include - optP_build/stage1/rts/build/autogen/cabal_macros.h -ghcversion-file=rts/include/ghcversion.h -outputdir _build/stage1/rts/build -fdiagnostics-color=always -Wnoncanonical-monad-instances -optc-Wno- error=inline -optP-Wno-nonportable-include-path -c rts/ContinuationOps.cmm -o _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o -O2 -H32m -this-unit-id rts -XHaskell98 -no-global-package-db - package-db=/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -haddock -Irts - I_build/stage1/rts/build '-DRtsWay="rts_debug_p"' -DFS_NAMESPACE=rts -DCOMPILING_RTS -DPROFILING -Wno-deprecated-flags -Wcpp-undef ===> Command failed with error code: 1 ghc: panic! (the 'impossible' happened) GHC version 9.6.5: PPC.Ppr.pprInstr: JMP to ForeignLabel CallStack (from HasCallStack): panic, called at compiler/GHC/CmmToAsm/PPC/Ppr.hs:591:30 in ghc:GHC.CmmToAsm.PPC.Ppr Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug Error when running Shake build system: at want, called at src/Main.hs:124:44 in main:Main * Depends on: binary-dist-dir at need, called at src/Rules/BinaryDist.hs:130:9 in main:Rules.BinaryDist * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.2.conf at need, called at src/Rules/Register.hs:134:5 in main:Rules.Register * Depends on: _build/stage1/rts/build/stamp-rts-1.0.2_debug_p at need, called at src/Rules/Library.hs:144:3 in main:Rules.Library * Depends on: _build/stage1/rts/build/libHSrts-1.0.2_debug_p.a at need, called at src/Rules/Library.hs:220:5 in main:Rules.Library * Depends on: _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o at cmd', called at src/Builder.hs:387:23 in main:Builder at cmdArgs, called at src/Builder.hs:540:8 in main:Builder at cmdArgs, called at src/Builder.hs:564:18 in main:Builder at cmdArgs, called at src/Builder.hs:564:18 in main:Builder at error, called at src/Builder.hs:609:13 in main:Builde
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias, On Thu, 2024-06-13 at 21:22 +0300, Ilias Tsitsimpis wrote: > Great job! Thanks! > I completely missed the fact this needs to be passes to the bindist's > configure script as well. It took me forever to figure this out ;-). > You need to edit debian/rules here > https://sources.debian.org/src/ghc/9.4.7-5/debian/rules/#L78 > and add the following line as well: > > + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override Yes, that's what I suggested, see my patch in [1]. > I will include that in the next upload. Great, thank you. I uploaded a patched version to unreleased in the mean time. > Do we still have to build an unregisterised compiler for powerpc > or can we switch back to NCG (https://bugs.debian.org/1060196)? I have not verified that yet. Please let's stay unregisterised for now and have me verify first whether the NGC has been fixed with 9.6.x or newer. Please let's keep this bug report open and use #1073159 [1] for adding the flag --disable-ld-override to EXTRA_INSTALL_CONFIGURE_FLAGS. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073159 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hey Adrian, On Thu, Jun 13, 2024 at 10:09AM, John Paul Adrian Glaubitz wrote: > Hi Jeff, > > On Thu, 2024-06-13 at 03:50 -0400, Jeffrey Walton wrote: > > > Now we just need to figure out how to actually set the default linker back > > > to bfd as it was actually explicitly supposed to happen according to > > > debian/rules. > > > > > > This will most likely also unbreak GHC on m68k. Great job! I completely missed the fact this needs to be passes to the bindist's configure script as well. You need to edit debian/rules here https://sources.debian.org/src/ghc/9.4.7-5/debian/rules/#L78 and add the following line as well: + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override I will include that in the next upload. Do we still have to build an unregisterised compiler for powerpc or can we switch back to NCG (https://bugs.debian.org/1060196)? -- Ilias
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Jeff, On Thu, 2024-06-13 at 03:50 -0400, Jeffrey Walton wrote: > > Now we just need to figure out how to actually set the default linker back > > to bfd as it was actually explicitly supposed to happen according to > > debian/rules. > > > > This will most likely also unbreak GHC on m68k. > > Good job, Adrian. That's quite a bit of work to track down the issue. Thanks. In the meantime I filed a bug upstream for this [1]. I will actually open a second bug report since this bug report is about the broken NGC on 32-bit PowerPC which is a different issue. Adrian > [1] https://gitlab.haskell.org/ghc/ghc/-/issues/24986 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
On Thu, Jun 13, 2024 at 3:41 AM John Paul Adrian Glaubitz wrote: > > I finally figured out what the problem is. > > After realizing that the two-stage build of GHC works without problems, > I realized it can be a configuration issue only and, indeed, it is. > > Looking at /usr/lib/ghc/lib/settings, the default linker is set to gold: > > "C compiler link flags", "-fuse-ld=gold" > > Since gold is broken on powerpc and shouldn't really be used anymore since > it's basically unmaintained upstream, we must use bfd on powerpc by default. > > Editing the file and switching back to bfd fixes the problem for me. > > Now we just need to figure out how to actually set the default linker back > to bfd as it was actually explicitly supposed to happen according to > debian/rules. > > This will most likely also unbreak GHC on m68k. Good job, Adrian. That's quite a bit of work to track down the issue. Jeff
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi, I finally figured out what the problem is. After realizing that the two-stage build of GHC works without problems, I realized it can be a configuration issue only and, indeed, it is. Looking at /usr/lib/ghc/lib/settings, the default linker is set to gold: "C compiler link flags", "-fuse-ld=gold" Since gold is broken on powerpc and shouldn't really be used anymore since it's basically unmaintained upstream, we must use bfd on powerpc by default. Editing the file and switching back to bfd fixes the problem for me. Now we just need to figure out how to actually set the default linker back to bfd as it was actually explicitly supposed to happen according to debian/rules. This will most likely also unbreak GHC on m68k. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
On Wed, 2023-10-11 at 18:02 +0300, Ilias Tsitsimpis wrote: > A small update here. I didn't manage to use the LLVM backend on i386, > seems to be broken [1]. I am trying to figure out now what it takes to build GHC using the LLVM backed on 32-bit PowerPC but it currently doesn't seem to be supported. I am not sure what needs to be patched to enable LLVM code generation for this target, but we will most likely need at least modify the script utils/llvm-targets/gen-data-layout.sh and probably a little more. If enabling LLVM support for a given target is not too involved, we could also look into enabling it for loong64, m68k and sparc64 which also have LLVM backends although the one for m68k is still in development. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Adrian, On Sun, Oct 15, 2023 at 09:01PM, John Paul Adrian Glaubitz wrote: > Unfortunately, we're running into another familiar problem which is a missing > -latomic > when building hadrian using the bootstrap.py script which does not take any > build flags, > the build of the »shake« package fails with the linker complaining about > unresolved > references to 64-bit atomic helper functions: > > Linking > /home/glaubitz/ghc18/ghc-9.4.7/hadrian/_build/dists/shake-0.19.4/build/shake/shake > ... > /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(STM.thr_o): in function > `stmStartTransaction': > (.text.stmStartTransaction+0xe4): undefined reference to `__atomic_load_8' > /usr/bin/ld: (.text.stmStartTransaction+0xfc): undefined reference to > `__atomic_store_8' > /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(STM.thr_o): in function > `stmCommitTransaction': > (.text.stmCommitTransaction+0x40): undefined reference to `__atomic_load_8' > /usr/bin/ld: (.text.stmCommitTransaction+0x118): undefined reference to > `__atomic_load_8' > /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(ThreadPaused.thr_o): in function > `threadPaused': > (.text.threadPaused+0x314): undefined reference to `__atomic_load_8' > /usr/bin/ld: (.text.threadPaused+0x32c): undefined reference to > `__atomic_store_8' > /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(Threads.thr_o): in function > `tryWakeupThread': > (.text.tryWakeupThread+0x194): undefined reference to `__atomic_load_8' > /usr/bin/ld: (.text.tryWakeupThread+0x1a8): undefined reference to > `__atomic_store_8' > /usr/bin/ld: (.text.tryWakeupThread+0x1c4): undefined reference to > `__atomic_load_8' > (...) > /usr/bin/ld: (.text.throwToMsg+0x444): undefined reference to > `__atomic_load_8' > /usr/bin/ld: (.text.throwToMsg+0x458): undefined reference to > `__atomic_store_8' > /usr/bin/ld: (.text.throwToMsg+0x478): undefined reference to > `__atomic_load_8' > /usr/bin/ld: (.text.throwToMsg+0x490): undefined reference to > `__atomic_store_8' > /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(SpinLock.thr_o): in function > `acquire_spin_lock_slow_path': > (.text.acquire_spin_lock_slow_path+0x64): undefined reference to > `__atomic_fetch_add_8' > /usr/bin/ld: (.text.acquire_spin_lock_slow_path+0x80): undefined reference to > `__atomic_fetch_add_8' > collect2: error: ld returned 1 exit status > `powerpc-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1) This is a problem with your custom GHC (9.0.3). I believe you need to use this patch as well [1], when building your custom GHC. I am surprised this didn't fail during build time. Also, take a look at the patches we have in Debian, there might be others that you need to use as well. [1] https://sources.debian.org/src/ghc/9.0.2-4/debian/patches/latomic-64bit/ > When building hadrian with "./hadrian/build -j", it's possible to pass the > necessary > "-latomic" with the help of "*.*.ghc.link.opts = -latomic". I assume, for the > bootstrap > python script, will have to patch either the Haskell sources or the Python > script. Note that "*.*.ghc.link.opts = -latomic" is parsed by hadrian itself, it will not affect how hadrian is built. I haven't tested it but I believe './hadrian/build -j "*.*.ghc.link.opts = -latomic"' will fail as well in your case. Best, -- Ilias
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hello! I have built a patched version 9.0.1 of GHC for powerpc with a forged 9.0.3 version number and uploaded it to unreleased so that we have a working bootstrap compiler to build 9.4.7 for powerpc once the bug has been fixed. Unfortunately, we're running into another familiar problem which is a missing -latomic when building hadrian using the bootstrap.py script which does not take any build flags, the build of the »shake« package fails with the linker complaining about unresolved references to 64-bit atomic helper functions: Linking /home/glaubitz/ghc18/ghc-9.4.7/hadrian/_build/dists/shake-0.19.4/build/shake/shake ... /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(STM.thr_o): in function `stmStartTransaction': (.text.stmStartTransaction+0xe4): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.stmStartTransaction+0xfc): undefined reference to `__atomic_store_8' /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(STM.thr_o): in function `stmCommitTransaction': (.text.stmCommitTransaction+0x40): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.stmCommitTransaction+0x118): undefined reference to `__atomic_load_8' /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(ThreadPaused.thr_o): in function `threadPaused': (.text.threadPaused+0x314): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.threadPaused+0x32c): undefined reference to `__atomic_store_8' /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(Threads.thr_o): in function `tryWakeupThread': (.text.tryWakeupThread+0x194): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.tryWakeupThread+0x1a8): undefined reference to `__atomic_store_8' /usr/bin/ld: (.text.tryWakeupThread+0x1c4): undefined reference to `__atomic_load_8' (...) /usr/bin/ld: (.text.throwToMsg+0x444): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.throwToMsg+0x458): undefined reference to `__atomic_store_8' /usr/bin/ld: (.text.throwToMsg+0x478): undefined reference to `__atomic_load_8' /usr/bin/ld: (.text.throwToMsg+0x490): undefined reference to `__atomic_store_8' /usr/bin/ld: /usr/lib/ghc/rts/libHSrts_thr.a(SpinLock.thr_o): in function `acquire_spin_lock_slow_path': (.text.acquire_spin_lock_slow_path+0x64): undefined reference to `__atomic_fetch_add_8' /usr/bin/ld: (.text.acquire_spin_lock_slow_path+0x80): undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status `powerpc-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1) When building hadrian with "./hadrian/build -j", it's possible to pass the necessary "-latomic" with the help of "*.*.ghc.link.opts = -latomic". I assume, for the bootstrap python script, will have to patch either the Haskell sources or the Python script. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
On Wed, 2023-10-11 at 18:29 +0300, Ilias Tsitsimpis wrote: > I think our best bet here is to bootstap GHC on these architectures, > that's why I have introduced the 'pkg.ghc.nohadrian' build profile. Let > me know if I can help, or if there is a better way to do it that I am > missing. OK, good to know about the build profile. However, on powerpc I will most likely still have to cross-compile the package as I don't really have a working native 9.0.x compiler on the target at the moment unless there is a 9.0.x version without the patch [1] that introduced the regression. Adrian > [1] > https://gitlab.haskell.org/ghc/ghc/-/commit/ba089952f034d91718c71f5ef297fe54818559df -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
On Wed, Oct 11, 2023 at 05:12PM, John Paul Adrian Glaubitz wrote: > I think you created a little hen and egg problem here by incorporating both > the switch to the Hadrian build system as well as the 32-bit unregisterised > and sparc64 build fixes into the same upload. > > Might a good idea to upload the two build fixes unstable first to get a > working > 9.4.x compiler for all targets so we're able to build haskell-hadrian first. Unfortunately we cannot currently build GHC from unstable, unless we use the Hadrian build system, see https://bugs.debian.org/1051493. It was a mistake uploading GHC 9.4.6 to unstable, without noticing that we need the new build system first. I think our best bet here is to bootstap GHC on these architectures, that's why I have introduced the 'pkg.ghc.nohadrian' build profile. Let me know if I can help, or if there is a better way to do it that I am missing. -- Ilias
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias! On Wed, 2023-10-11 at 18:02 +0300, Ilias Tsitsimpis wrote: > A small update here. I didn't manage to use the LLVM backend on i386, > seems to be broken [1]. > > Instead, I believe I have managed to fix unregisterised GHC on 32-bit, > by backporting these two patches [2] [3]. Can you try building an > unregisterised GHC 9.4.7 on powerpc and see if this resolves the issues > you have with integer overflows? Note that GHC 9.4.7 *with* the Hadrian > build system is now available on experimental. I think you created a little hen and egg problem here by incorporating both the switch to the Hadrian build system as well as the 32-bit unregisterised and sparc64 build fixes into the same upload. Might a good idea to upload the two build fixes unstable first to get a working 9.4.x compiler for all targets so we're able to build haskell-hadrian first. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Adrian, On Wed, Oct 04, 2023 at 11:59AM, John Paul Adrian Glaubitz wrote: > > 2. An unregisterised GHC 9.0.2 is *also* broken on powerpc, producing > > code that overflows integers. We are also seeing unregisterised GHC > > 9.4.6 on i386 being broken, since the tests for haskell-quickcheck fail > > (see > > https://buildd.debian.org/status/package.php?p=haskell-quickcheck&suite=sid). > > The plan for i386 is to registerise GHC and use the LLVM backend by > > default (to avoid the baseline violation). > > I see. A small update here. I didn't manage to use the LLVM backend on i386, seems to be broken [1]. Instead, I believe I have managed to fix unregisterised GHC on 32-bit, by backporting these two patches [2] [3]. Can you try building an unregisterised GHC 9.4.7 on powerpc and see if this resolves the issues you have with integer overflows? Note that GHC 9.4.7 *with* the Hadrian build system is now available on experimental. [1] https://gitlab.haskell.org/ghc/ghc/-/issues/24018 [2] https://salsa.debian.org/haskell-team/DHG_packages/-/blob/a38be7c092b024de04280f0a72642baf283cea01/p/ghc/debian/patches/fix-32-bit-unreg [3] https://salsa.debian.org/haskell-team/DHG_packages/-/blob/a38be7c092b024de04280f0a72642baf283cea01/p/ghc/debian/patches/fix-hs_cmpxchg64 -- Ilias
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
On 09 oct. 2023 09:32, John Paul Adrian Glaubitz wrote: [...] > I think the interesting part would be the disassembly of > base_GHCziFloat_floatToDigits_closure () > where the actual crash happened. Your disassembly seems to show parts > of the segfault handler. , | 10a19f20 : | 10a19f20: 10 83 c0 48 vmulouh v4,v3,v24 | 10a19f24: 10 a2 0d bc vaddeuqm v5,v2,v1,v22 | 10a19f28: 10 a1 9e 80 vsubuws v5,v1,v19 | 10a19f2c: 10 a1 9e b0 maddhd r5,r1,r19,r26 | 10a19f30: 10 a1 9e d0 zvdotphssui r5,r1,r19 | 10a19f34: 10 a1 9f 10 .long 0x10a19f10 | 10a19f38: 00 00 00 00 .long 0x0 | 10a19f3c: 10 90 f7 d0 .long 0x1090f7d0 | 10a19f40: 10 a1 9c 18 vextdubvlx v5,v1,v19,r16 | 10a19f44: 10 a1 9c c0 vsubudm v5,v1,v19 | 10a19f48: 00 00 00 00 .long 0x0 | 10a19f4c: 10 90 f7 f0 maddhd r4,r16,r30,r31 | 10a19f50: 10 a1 9c 08 vpmsumb v5,v1,v19 | 10a19f54: 10 a1 9f 00 vsubsbs v5,v1,v19 | 10a19f58: 10 a1 9f 3c vaddeuqm v5,v1,v19,v28 | 10a19f5c: 00 00 00 00 .long 0x0 | 10a19f60: 10 90 f7 d0 .long 0x1090f7d0 | 10a19f64: 10 a1 9f 20 vmhaddshs v5,v1,v19,v28 | 10a19f68: 10 a1 9f 4c psq_lux f5,r1,r19,1,6 | 10a19f6c: 00 00 00 00 .long 0x0 ` Christian
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Christian! On Mon, 2023-10-09 at 09:25 +0200, Christian Marillat wrote: > > On Mon, 2023-10-09 at 08:57 +0200, Christian Marillat wrote: > > > > Could you provide the disassembled code for the affected code section? > > Is this enough ? > > , > > Dump of assembler code for function __GI_kill: > >0xf7644b94 <+0>: li r0,37 > >0xf7644b98 <+4>: sc > > => 0xf7644b9c <+8>: bnslr+ > >0xf7644ba0 <+12>:b 0xf762a200 <__syscall_error> > > End of assembler dump. > ` I think the interesting part would be the disassembly of base_GHCziFloat_floatToDigits_closure () where the actual crash happened. Your disassembly seems to show parts of the segfault handler. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
On 09 oct. 2023 08:59, John Paul Adrian Glaubitz wrote: > Hi Christian! Hi Adrian, > On Mon, 2023-10-09 at 08:57 +0200, Christian Marillat wrote: >> > Could you provide the disassembled code for the affected code section? Is this enough ? , | Dump of assembler code for function __GI_kill: |0xf7644b94 <+0>: li r0,37 |0xf7644b98 <+4>: sc | => 0xf7644b9c <+8>: bnslr+ |0xf7644ba0 <+12>: b 0xf762a200 <__syscall_error> | End of assembler dump. ` Christian
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Christian! On Mon, 2023-10-09 at 08:57 +0200, Christian Marillat wrote: > > Could you provide the disassembled code for the affected code section? > > I don't remember but now I can install ghc (>= 9.4) only 9.0.2 is > available. The bug affects GHC 9.0.2 as the change was backported. GHC 9.4.x was never available for powerpc at the moment due this particular bug. > Is it important ? It would save me some time, so it would be very helpful. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
On 05 oct. 2023 22:34, John Paul Adrian Glaubitz wrote: > Hi Christian! Hi Adrian, [...] > Could you provide the disassembled code for the affected code section? I don't remember but now I can install ghc (>= 9.4) only 9.0.2 is available. Is it important ? Christian
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Christian! > , > | Reading symbols from > /home/marillat/haskell-random-1.2.1.1/debian/hlibrary.setup... > | (No debugging symbols found in > /home/marillat/haskell-random-1.2.1.1/debian/hlibrary.setup) > | [New LWP 9082] > | [Thread debugging using libthread_db enabled] > | Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1". > | Core was generated by `debian/hlibrary.setup build --builddir=dist-ghc'. > | Program terminated with signal SIGSEGV, Segmentation fault. > | #0 __GI_kill () at ../sysdeps/unix/syscall-template.S:122 > | 122 ../sysdeps/unix/syscall-template.S: No such file or directory. > | (gdb) bt > | #0 __GI_kill () at ../sysdeps/unix/syscall-template.S:122 > | #1 0x108f27b4 in exitBySignal () > | #2 0x108f29f4 in shutdownHaskellAndSignal () > | #3 0x1088c828 in ?? () > | #4 0x108f55a0 in scheduleWaitThread () > | #5 0x108f21c8 in hs_main () > | #6 0x10007408 in main () > | (gdb) > ` Could you provide the disassembled code for the affected code section? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias! On Wed, 2023-10-04 at 12:26 +0200, John Paul Adrian Glaubitz wrote: > Looking at the ghc package in openSUSE, I found this patch [1] which disables > unboxed arrays > in order to fix the build on big-endian systems. And, indeed, disabling > unboxed arrays in > libraries/containers/containers/include/containers.h allows me to fully build > ghc from git > on 32-bit PowerPC. See also [2]. I managed to track this down to this commit [1]: ba089952f034d91718c71f5ef297fe54818559df is the first bad commit commit ba089952f034d91718c71f5ef297fe54818559df Author: Sylvain Henry Date: Fri Jan 15 12:33:40 2021 +0100 Bignum: add Natural constant folding rules (#15821) * Implement constant folding rules for Natural (similar to Integer ones) * Add mkCoreUbxSum helper in GHC.Core.Make * Remove naturalTo/FromInt We now only provide `naturalTo/FromWord` as the semantics is clear (truncate/zero-extend). For Int we have to deal with negative numbers (throw an exception? convert to Word beforehand?) so we leave the decision about what to do to the caller. Moreover, now that we have sized types (Int8#, Int16#, ..., Word8#, etc.) there is no reason to bless `Int#` more than `Int8#` or `Word8#` (for example). * Replaced a few `()` with `void#` compiler/GHC/Builtin/Names.hs | 310 +++--- compiler/GHC/Core/Make.hs | 14 +- compiler/GHC/Core/Opt/ConstantFold.hs | 670 +++-- compiler/GHC/HsToCore/Expr.hs | 6 +- compiler/GHC/Types/Id/Make.hs-boot | 1 + libraries/base/GHC/Enum.hs | 4 +- libraries/base/GHC/Float.hs| 6 +- libraries/base/GHC/Int.hs | 16 +- libraries/base/GHC/Natural.hs | 20 +- libraries/base/GHC/Num.hs | 12 +- libraries/base/GHC/Real.hs | 2 +- libraries/ghc-bignum/src/GHC/Num/BigNat.hs | 64 +- libraries/ghc-bignum/src/GHC/Num/Integer.hs| 14 +- libraries/ghc-bignum/src/GHC/Num/Natural.hs| 162 +++-- libraries/ghc-bignum/src/GHC/Num/Primitives.hs | 4 +- libraries/ghc-bignum/src/GHC/Num/WordArray.hs | 4 +- .../integer-gmp/src/GHC/Integer/GMP/Internals.hs | 8 +- testsuite/tests/lib/integer/Makefile | 50 +- testsuite/tests/lib/integer/all.T | 1 + .../tests/lib/integer/naturalConstantFolding.hs| 172 ++ .../lib/integer/naturalConstantFolding.stdout | 38 ++ testsuite/tests/perf/compiler/T16473.stdout| 2 +- .../tests/simplCore/should_compile/T15445.stderr | 2 +- 23 files changed, 1057 insertions(+), 525 deletions(-) create mode 100644 testsuite/tests/lib/integer/naturalConstantFolding.hs create mode 100644 testsuite/tests/lib/integer/naturalConstantFolding.stdout And I have verified that this commit actually introduced the segfault on 32-bit PowerPC. Adrian > [1] > https://gitlab.haskell.org/ghc/ghc/-/commit/ba089952f034d91718c71f5ef297fe54818559df -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi! On Wed, 2023-10-04 at 11:59 +0200, John Paul Adrian Glaubitz wrote: > FWIW, I have not been able to build GHC from git on 32-bit PowerPC even for > 8.10.7. I assume, > I will need to add some of Debian's patches on top of vanilla GHC in order to > get the build > to succeed. > > Trying to build GHC 9.0.2 fails for example with: > > > http://paste.debian.net/hidden/31954e9a/ Looking at the ghc package in openSUSE, I found this patch [1] which disables unboxed arrays in order to fix the build on big-endian systems. And, indeed, disabling unboxed arrays in libraries/containers/containers/include/containers.h allows me to fully build ghc from git on 32-bit PowerPC. See also [2]. I have now a working reproducer and can now start bisecting between 8.10.7 and 9.0.2. Adrian > [1] > https://build.opensuse.org/package/view_file/devel:languages:haskell/ghc/Disable-unboxed-arrays.patch?expand=1 > [2] https://gitlab.haskell.org/ghc/ghc/-/issues/16998 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias! On Wed, 2023-09-20 at 14:54 +0300, Ilias Tsitsimpis wrote: > Thanks for working on this, comments inline. Thanks for the useful hints! > On Wed, Sep 20, 2023 at 12:15PM, John Paul Adrian Glaubitz wrote: > > I have been bisecting this issue but in order to be successful, I need a > > simple > > reproducer which isn't trivial since I cannot just reuse the build > > directory of > > an unsuccessful build due to the changing Haskell libraries for different > > GHC > > versions. > > > > Ideally, we should have a single command line with GHC which will trigger > > the > > segmentation fault. > > Are you bisecting the segfault issue? If yes, then a simple reproducer > would be to try and compile haskell-random. > > Since you already have cabal-install on your system, you can do > something like: > > $ cabal install --with-ghc=/usr/bin/ghc --with-ghc-pkg=/usr/bin/ghc-pkg > random-1.2.1.1 > > (replace ghc and ghc-pkg with the ones you have built). Thanks, this is the exact reproducer I need. I can reproduce the crash using this command line inside a 32-bit PowerPC chroot on perotto with ghc 9.0.2. > > To bisect, I have done the following: > > > > # git bisect start > > # git bisect good ghc-8.10.7-release > > # git bisect bad ghc-9.2.7-release > > Since this issue is also present in ghc-9.0.2, maybe we can start from > there. Yes, that's what I am trying now as well. > > # git submodule update --init > > # ./boot ; python3 boot > > # echo "SRC_HC_OPTS += -lffi -latomic -optl-pthread" >> mk/build.mk && \ > > echo "Stage1Only := YES" >> mk/build.mk && \ > > echo 'utils/genprimopcode_CONFIGURE_OPTS += "-f-build-tool-depends"' \ > > >> mk/build.mk && echo 'compiler_CONFIGURE_OPTS += > > "-f-build-tool-depends"' \ > > >> mk/build.mk && echo 'utils/hpc_CONFIGURE_OPTS += > > "-f-build-tool-depends"' \ > > >> mk/build.mk && echo "HADDOCK_DOCS := NO" >> mk/build.mk \ > > && echo "BUILD_SPHINX_HTML := NO" >> mk/build.mk && echo > > "BUILD_SPHINX_PDF := NO" \ > > >> mk/build.mk > > # ./configure && make -j32 > > > > For newer versions, the build has to be performed with Hadrian, so the last > > step > > would be: > > > > # ./hadrian/build -j > > Keep in mind that hadrian doesn't take into account 'mk/build.mk'. You > will have to configure hadrian in the same way, see also > https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html. Thanks, good to know! > Let me summarize the current state to make sure we are not missing > anything: > > 1. GHC 9.0.2 with the native code generator is currently broken on > powerpc and segfaults while building (at least) haskell-random and > GHC-9.4.6. Strangely enough, we can compile GHC 9.0.2 itself. > > 2. An unregisterised GHC 9.0.2 is *also* broken on powerpc, producing > code that overflows integers. We are also seeing unregisterised GHC > 9.4.6 on i386 being broken, since the tests for haskell-quickcheck fail > (see > https://buildd.debian.org/status/package.php?p=haskell-quickcheck&suite=sid). > The plan for i386 is to registerise GHC and use the LLVM backend by > default (to avoid the baseline violation). I see. > 3. We cannot cross-compile GHC 9.4 and newer any more (we are discussing > this here as well https://gitlab.haskell.org/ghc/ghc/-/issues/23975). This can be trivially fixed with the help of this patch: > https://gitlab.haskell.org/ghc/ghc/-/commit/9cb385098f2dfd647c13ca509d71786c56277cff > Given the above, I can think of the following: > > 1. Fix the native code generator in GHC 9.0.2 > 2. Fix unregisterised GHCs on 32-bit architectures FWIW, I am seeing the overflow on 32-bit PowerPC only. I don't see it on m68k, for example. > 3. Try and use the LLVM backend in GHC 9.0.2 on powerpc, and see if this > produces valid code and allows us to compile GHC 9.4.6. Ah, that's actually a possible approach to take. FWIW, I have not been able to build GHC from git on 32-bit PowerPC even for 8.10.7. I assume, I will need to add some of Debian's patches on top of vanilla GHC in order to get the build to succeed. Trying to build GHC 9.0.2 fails for example with: > http://paste.debian.net/hidden/31954e9a/ > For the record, I have started working on migrating GHC in Debian to use > the new Hadrian build system, you can find the latest code here > https://salsa.debian.org/haskell-team/DHG_packages/-/tree/hadrian. I am > at a really good state right now where I can build GHC, and doing a lot > of tests to verify I haven't missed anything. If you are working on GHC > right now as well, I would appreciate if you can take a look, and/or > start using this branch for all your tests, so we catch any errors > early. I want to get the build issue on 32-bit PowerPC sorted out first. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Adrian, Thanks for working on this, comments inline. On Wed, Sep 20, 2023 at 12:15PM, John Paul Adrian Glaubitz wrote: > I have been bisecting this issue but in order to be successful, I need a > simple > reproducer which isn't trivial since I cannot just reuse the build directory > of > an unsuccessful build due to the changing Haskell libraries for different GHC > versions. > > Ideally, we should have a single command line with GHC which will trigger the > segmentation fault. Are you bisecting the segfault issue? If yes, then a simple reproducer would be to try and compile haskell-random. Since you already have cabal-install on your system, you can do something like: $ cabal install --with-ghc=/usr/bin/ghc --with-ghc-pkg=/usr/bin/ghc-pkg random-1.2.1.1 (replace ghc and ghc-pkg with the ones you have built). > To bisect, I have done the following: > > # git bisect start > # git bisect good ghc-8.10.7-release > # git bisect bad ghc-9.2.7-release Since this issue is also present in ghc-9.0.2, maybe we can start from there. > # git submodule update --init > # ./boot ; python3 boot > # echo "SRC_HC_OPTS += -lffi -latomic -optl-pthread" >> mk/build.mk && \ > echo "Stage1Only := YES" >> mk/build.mk && \ > echo 'utils/genprimopcode_CONFIGURE_OPTS += "-f-build-tool-depends"' \ > >> mk/build.mk && echo 'compiler_CONFIGURE_OPTS += "-f-build-tool-depends"' > \ > >> mk/build.mk && echo 'utils/hpc_CONFIGURE_OPTS += > "-f-build-tool-depends"' \ > >> mk/build.mk && echo "HADDOCK_DOCS := NO" >> mk/build.mk \ > && echo "BUILD_SPHINX_HTML := NO" >> mk/build.mk && echo "BUILD_SPHINX_PDF > := NO" \ > >> mk/build.mk > # ./configure && make -j32 > > For newer versions, the build has to be performed with Hadrian, so the last > step > would be: > > # ./hadrian/build -j Keep in mind that hadrian doesn't take into account 'mk/build.mk'. You will have to configure hadrian in the same way, see also https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html. Let me summarize the current state to make sure we are not missing anything: 1. GHC 9.0.2 with the native code generator is currently broken on powerpc and segfaults while building (at least) haskell-random and GHC-9.4.6. Strangely enough, we can compile GHC 9.0.2 itself. 2. An unregisterised GHC 9.0.2 is *also* broken on powerpc, producing code that overflows integers. We are also seeing unregisterised GHC 9.4.6 on i386 being broken, since the tests for haskell-quickcheck fail (see https://buildd.debian.org/status/package.php?p=haskell-quickcheck&suite=sid). The plan for i386 is to registerise GHC and use the LLVM backend by default (to avoid the baseline violation). 3. We cannot cross-compile GHC 9.4 and newer any more (we are discussing this here as well https://gitlab.haskell.org/ghc/ghc/-/issues/23975). Given the above, I can think of the following: 1. Fix the native code generator in GHC 9.0.2 2. Fix unregisterised GHCs on 32-bit architectures 3. Try and use the LLVM backend in GHC 9.0.2 on powerpc, and see if this produces valid code and allows us to compile GHC 9.4.6. For the record, I have started working on migrating GHC in Debian to use the new Hadrian build system, you can find the latest code here https://salsa.debian.org/haskell-team/DHG_packages/-/tree/hadrian. I am at a really good state right now where I can build GHC, and doing a lot of tests to verify I haven't missed anything. If you are working on GHC right now as well, I would appreciate if you can take a look, and/or start using this branch for all your tests, so we catch any errors early. Best, -- Ilias
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hello! I have been bisecting this issue but in order to be successful, I need a simple reproducer which isn't trivial since I cannot just reuse the build directory of an unsuccessful build due to the changing Haskell libraries for different GHC versions. Ideally, we should have a single command line with GHC which will trigger the segmentation fault. To bisect, I have done the following: # git bisect start # git bisect good ghc-8.10.7-release # git bisect bad ghc-9.2.7-release # git submodule update --init # ./boot ; python3 boot # echo "SRC_HC_OPTS += -lffi -latomic -optl-pthread" >> mk/build.mk && \ echo "Stage1Only := YES" >> mk/build.mk && \ echo 'utils/genprimopcode_CONFIGURE_OPTS += "-f-build-tool-depends"' \ >> mk/build.mk && echo 'compiler_CONFIGURE_OPTS += "-f-build-tool-depends"' \ >> mk/build.mk && echo 'utils/hpc_CONFIGURE_OPTS += "-f-build-tool-depends"' \ >> mk/build.mk && echo "HADDOCK_DOCS := NO" >> mk/build.mk \ && echo "BUILD_SPHINX_HTML := NO" >> mk/build.mk && echo "BUILD_SPHINX_PDF := NO" \ >> mk/build.mk # ./configure && make -j32 For newer versions, the build has to be performed with Hadrian, so the last step would be: # ./hadrian/build -j Prior to using Hadrian for the first time, the package database needs to be updated: # cabal update Now, if I had a simple reproducer, it would be rather easy to bisect the issue. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi! Note that this issue also prevents us from building the latest version of the GHC compiler [1]. I have tried to cross-compile GHC 9.4.6 to work around this issue and also tried building an unregisterised compiler. Both without success. I have forwarded the issue upstream [2]. I think the only way forward will be to bisect the problem unless a GHC expert can figure out what the problem is. Adrian > [1] https://buildd.debian.org/status/package.php?p=ghc&suite=sid > [2] https://gitlab.haskell.org/ghc/ghc/-/issues/23969 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
