ghc-6.10.0.20081007 seg faults on Sparc

[maeder]

My attempt to build ghc-6.10.0.20081007 on a sparc created a stage2 compiler that seq-faults. I don't have much time (and no idea how) to continue:

cabal-bin: ghc version >=6.4 is required but the version of
/export/local2/home/maeder/haskell/ghc-6.10.0.20081007/ghc/stage2-inplace/ghc
could not be determined.
gmake[3]: *** [with-stage-2] Error 1
gmake[3]: Leaving directory `/export/local2/home/maeder/haskell/ghc-6.10.0.20081007/utils/installPackage'
gmake[2]: *** [with-stage-2.installPackage] Error 2
gmake[2]: Leaving directory `/export/local2/home/maeder/haskell/ghc-6.10.0.20081007/utils'
gmake[1]: *** [stage2] Error 2
gmake[1]: Leaving directory `/export/local2/home/maeder/haskell/ghc-6.10.0.20081007'
gmake: *** [bootstrap2] Error 2

-bash-3.00$ /export/local2/home/maeder/haskell/ghc-6.10.0.20081007/ghc/stage2-inplace/libexec/ghc
ghc: missing -B<dir> option
Segmentation Fault

[maeder]

Starting program: /export/local2/home/maeder/haskell/ghc-6.10.0.20081007/ghc/stage2-inplace/libexec/ghc
warning: Lowest section in /lib/libdl.so.1 is .hash at 000000b4
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074
[New LWP 1]
[New LWP 2]
[New LWP 3]
ghc: missing -B<dir> option

Program received signal SIGSEGV, Segmentation fault.
0x0132a6b0 in todo_block_full ()
(gdb)

[simonmar]

Could you try re-linking stage2 with -debug, which should get you a better stack trace.

$ cd ghc
$ make rebuild stage=2 GhcDebugged=YES

[maeder]

it shows now:

[New LWP 3]
ghc: missing -B<dir> option
ghc: internal error: ASSERTION FAILED: file sm/GCUtils.c, line 140

    (GHC version 6.10.0.20081007 for sparc_sun_solaris2)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Program received signal SIGABRT, Aborted.
0xff14642c in _lwp_kill () from /lib/libc.so.1
(gdb)

[maeder]

the machine used is:

SunOS 5.10 Generic_137111-07 sun4u sparc SUNW,Sun-Fire-280R

-bash-3.00$ gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.2.2/configure --prefix=/usr/local/lang -program-suffix=_4.2.2 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs --enable-languages=c,c++
Thread model: posix
gcc version 4.2.2

I've also tried a different machine, where the stage2 compiler just sleeps and seg-faults without failure position when relinked with GhcDebugged=YES.

SunOS 5.10 Generic_137111-03 sun4u sparc SUNW,Sun-Fire-V240

-bash-3.00$ gcc -v
Reading specs from /export/local/lang/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.4/specs
Configured with: ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4_s10 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.4

[benl]

The problem seems to be caused by using a pinned register for gc_thread in rts/sm/GCThread.h. I'm testing a patch for this now.

[maeder]

With your patch I was able to create a working stage2 compiler. A minimal binary-dist without extra-libs is under  http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/solaris/ghcs/ghc-6.10.1-sparc-sun-solaris2.tar.bz2

[igloo]

Thanks for the bindist, I've added it to the 6.10.1 download page.

[duncan]

We should push Ben's patch to the 6.10 branch

Mon Jan  5 04:07:58 CET 2009  Ben.Lippmeier@anu.edu.au
  * Don't pin a register for gc_thread on SPARC.

[maeder]

Wrt my binary-dist I forgot to mention that it was compiled with gcc-4.2.2, but I was able to use it with gcc-3.4.4 after removing -fno-toplevel-reorder from extra-gcc-opts

Under linux and macs there are -mno-omit-leaf-frame-pointer -fno-unit-at-a-time in extra-gcc-opts. May the lack of any of these options be responsible for the long compilation times observed with gcc-4.2.x #2906?

[maeder]

This ticket can be closed, as the patch fixed it.

[simonmar]

Replying to maeder:

This ticket can be closed, as the patch fixed it.

The patch is really a workaround, we should find out why gcc the GC gets miscompiled when the register variable is used.

[igloo]

Replying to duncan:

We should push Ben's patch to the 6.10 branch {{{ Mon Jan 5 04:07:58 CET 2009 Ben.Lippmeier@… * Don't pin a register for gc_thread on SPARC. }}}

Done.

[benl]

The GC gets miscompiled when the register variable is used because names like %l1 and %i1 are just offsets into the register window. In C land, when a function call takes place the window moves, so we lose the value of gct. We can't use any of the global regs %g0 - %g7 either because their either reserved for other purposes or caller-saves.