And so it begins... (ghc-5.04 bootstrapped for sparc-unknown-linux)
[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
participants (1)
-
Michael Weber