[In a hurry...] Hi, michaelw@repo ~/debian/ghc5/ghc5-5.04/build-stage1/ [225]% uname -a Linux repo 2.4.18 #11 Mon Jun 17 20:37:46 CEST 2002 sparc64 unknown michaelw@repo ~/debian/ghc5/ghc5-5.04/build-stage1/ [226]% echo 'module Main where main = putStrLn "Hello, World!"' > Main.hs michaelw@repo ~/debian/ghc5/ghc5-5.04/build-stage1/ [227]% ghc/compiler/ghc-inplace Main.hs /tmp/ghc27784.hc:53: warning: initialization discards qualifiers from pointer target type michaelw@repo ~/debian/ghc5/ghc5-5.04/build-stage1/ [228]% ./a.out Hello, World! michaelw@repo ~/debian/ghc5/ghc5-5.04/build-stage1/ [229]% Just to let you know, I bootstrapped GHC on sparc{32,64}-unknown-linux (sparc64 userland is (mostly) 32bit on Linux, at least for now). Packages (binary + source) are available at: http://lambda.foldr.org/~michaelw/haskell/ !!! DISCLAIMER !!! These packages are experimental, made in a hurry, not very well tested, and will likely eat your hamster or just refuse to work. They're merely meant as appetizers and to play around a bit. Unfortunately, there are only Debian packages[1] of the GHC suite (ghc5, happy, haddock) available, since a regular (tarball) binary distributions requires an option to be set _before_ the build (which I didn't) and time is running out... I'll be away from literally now until ~2002-08-11, possibly with no inet access at all. After I am back, I'll have a look on the todo list items. Please be patient (or fix it yourself and send patches :) ) So, go ahead, fill my inbox... ;) Cheers, Michael What works: * unregisterized compilation: I had to be a bit creative with the LOOKS_LIKE_GHC_INFO stuff (which is one fragile piece of sh^H^Hcode... ;)), since gcc on sparc-linux doesn't mark the beginning of .data (like "data_start" on i386-linux). And using etext is definitely wrong here[2], since .rodata comes afterwards and therefore etext doesn't cover the info tables for static closures(?) (like stg_BLACKHOLE_info). Wouldn't be an issue once TABLES_NEXT_TO_CODE works (i.e. registerized compilation). But I think my work-around will always work (at least with GNU ld): mark the start of the data section ourselves with a linker script (grep the diff.gz for "linker_majik"). BTW: If I am not mistaken, the first object file determines the order of the sections, so one can easily confuse the RTS by using a completely valid, but slightly reordered object file as first linker input file... yuck! * compiler compiled itself; happy and haddock also work and are available. * debugging RTS enabled so hopefully the testers can make some sense out of the core dumps. :) To Do: * registerized compilation: resulting binaries all die with bus error[3], due to an unaligned jmp to 0xc0f12 (xxx_info not aligned right). Note how the entry point is actually 0xc0f14! Modifying it to the right value gets us further into the program, until the next one is off-by-two. No idea[4] where this comes from, I just re-used the sparc-*-solaris mangler for a start... Everything in the base library seems to be affected. Maybe it's due to a botched build, since _sometimes_ xxx_info and xxx_entry match and hence the RTS does jump to the right entry point (e.g. Main_zdmain_info/entry). The devel system is tight on resources, so I had to er... "improvize"... :) (BTW: 64MB phys. RAM is no fun if the compiler binary is ~20MB stripped...) Up to the point where the trap occurs, it looks promising AFAICT, the first few closures behaved well. I guess it's normal that the xxx_info tables look weird in gdb since they are laid out backwards? * GHCi: dies with unresolved symbols while loading HSbase_cbits.o (__umoddi3 and friends; again: maybe just due to a wrong build...) * get rid of all those scary warnings :) * folding back changes to CVS * make bootstrapping work with uh... less hand-waving, praying/swearing in the general direction of Glasgow, etc. ;) [1] the Debian packages are fairly easy to unpack manually. Just use "mkdir foo && cd foo && ar x ../foo.deb && tar xvzf data.tar.gz" That leaves you with a foo/usr/{bin/lib,share}/ hierarchy. The actual binaries are in usr/lib/ghc-5.04/bin. Now, getting the right libraries is another matter... :) Come to think of it, I'll drop a single, statically linked binary of ghc-5.04 under the above mentioned URL. [2] I wonder how this all works out on sparc-*-solaris*... After a (very) short look I guessed the situation is similar there. Somebody please correct me if I overlooked something... [3] gdb output of a "module Main where main = return ()" crash: (gdb) disas 0x11b30 0x11b4c Dump of assembler code from 0x11b30 to 0x11b4c: 0x11b30 <Main_zdmain_info+152>: st %g3, [ %i0 + -16 ] 0x11b34 <Main_zdmain_info+156>: sethi %hi(0x22cc00), %l1 0x11b38 <Main_zdmain_info+160>: or %l1, 0x6c, %l1 ! 0x22cc6c <GHCziTopHandler_runIO_closure> 0x11b3c <Main_zdmain_info+164>: add %i0, -16, %i0 0x11b40 <Main_zdmain_info+168>: ld [ %l1 ], %g3 0x11b44 <Main_zdmain_info+172>: jmp %g3 0x11b48 <Main_zdmain_info+176>: nop End of assembler dump. (gdb) i r g3 g3 0xc0f12 790290 (gdb) si Program received signal SIGBUS, Bus error. 0x00011b44 in Main_zdmain_info () (gdb) p &GHCziTopHandler_runIO_entry $1 = (<text variable, no debug info> *) 0xc0f14 <GHCziTopHandler_runIO_entry> (gdb) p &GHCziTopHandler_runIO_info $2 = (<text variable, no debug info> *) 0xc0f12 <GHCziTopHandler_runIO_info> (gdb) bt #0 0x00011b44 in Main_zdmain_info () #1 0x00011af8 in Main_zdmain_info () #2 0x001fc494 in schedule () at Schedule.c:1060 #3 0x001fcd58 in waitThread_ (m=0x247090) at Schedule.c:2257 #4 0x001fcd44 in waitThread (tso=0x500c0000, ret=0x0) at Schedule.c:2214 #5 0x001fb6c8 in rts_mainEvalIO (p=0x226028, ret=0x0) at RtsAPI.c:489 #6 0x001fb084 in main (argc=1, argv=0xeffffd84) at Main.c:106 (gdb) [4] Well, "no idea" is not entirely true. At first I intended to investigate the JMP_ macro resp. includes/ClosureMacros.h a little closer (many warning during compilation), but then decided to roll the packages first...