Re: 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
Reply to: