mips-sgi-irix bootstrapping

[Simon Marlow]

> -----------
> 32 bit mips
> -----------
> 
> * apply rmartine's latest CVS patch to MBlock.c
> 
> * The build will go through once, but when you then have to 
> rebuild the
> rts, pkg-conf will crash creating driver/package.conf.inplace. The
> solution is to manually echo "[]" > 
> driver/package.conf.inplace, and to
> touch driver/stamp-pkg-conf-rts
> 
> * The build will dump core in the rts. Fire up gdb and you'll 
> see that it 
> died in gmp code around "__gmpn_tdiv_qr".
> 
> The solution is to build an external libgmp, and override the target
> architecture in the gmp build with ./configure --build=mips-sgi-irix.
> This forces gmp to use 32 bit assembly, rather than going for 64 bit
> code, which it does by default.
> 
> * The build then crashes in __decodeDouble (), in GC.c, I 
> think it was.

There is probably a 32/64 bit mismatch somewhere.  You should be able to
find out more by compiling up the RTS with debugging options and
stepping through decodeDouble (this is ordinary C code).

> ------
> 64 bit
> ------
> 
> The libraries and compiler go though nicely, although you may see
> warnings of the kind:
> 
>   ghc/Num.hc:5303: warning: this decimal constant is unsigned 
> only in ISO C90

Might be to do with some 64-bit constants in the generated .hc files,
but I'm not sure.

> * My current bug: following distrib/hc-build, after bootstrapping ghc/
> we rebuild the rts and libraries with the ghc binrary. AutoApply.hc is
> generated. ghc then can't compile this file. If you look carefully at
> the bottom of AutoApply.hc you'll see some strange characters:
> 
>     [ARG_8??] MK_SMALL_BITMAP(3,6),
>     [ARG_8?8] MK_SMALL_BITMAP(3,2),
>     [ARG_88?] MK_SMALL_BITMAP(3,4),
>     [ARG_888] MK_SMALL_BITMAP(3,0),
>     [ARG_8888] MK_SMALL_BITMAP(4,0),
>     [ARG_88888] MK_SMALL_BITMAP(5,0),
> 
> This is a problem! The ARG_xxx characters should be either N or P or a
> some other characters. Not strange ones as we see. 

Aha!  It looks like toUpper isn't working properly.  This is probably
because GHC.Unicode has been compiled for a 32-bit machine.  

This is my fault :-(  GHC.Unicode is processed by hsc2hs, which bakes in
some platform-specific stuff into the .hs code before compiling it.  The
trouble is that hsc2hs is currently running on the host machine rather
than the target machine, so GHC.Unicode is currently being compiled with
32-bit assumptions.  This hasn't been a problem so far because we've
eradicated hsc2hs code from the critical path, but I forgot about this
when I introduced GHC.Unicode recently.  oops!

The solution for the time being is to take the C code generated by
hsc2hs on the host machine using the --no-compile option, compile & run
the program on the target machine using gcc, then take the .hs back to
the host machine to generate the .hc file.  Or you can wait till I've
turned GHC.Unicode back into a plain .hs file.

Cheers,
	Simon