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
