And so it begins... (ghc-5.04 bootstrapped for sparc-unknown-linux)
Michael Weber
michaelw@foldr.org
Tue, 30 Jul 2002 03:34:05 +0200
--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
[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 =3D putStrLn "Hello, World!"' > Main.hs
michaelw@repo ~/debian/ghc5/ghc5-5.04/build-stage1/
[227]% ghc/compiler/ghc-inplace Main.hs =20
/tmp/ghc27784.hc:53: warning: initialization discards qualifiers from point=
er 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]%=20
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 !!!
=20
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. :)
=20
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...)
=20
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? =20
* GHCi:
dies with unresolved symbols while loading HSbase_cbits.o
(__umoddi3 and friends; again: maybe just due to a wrong build...)
=20
* 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. ;)
=20
[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.
=20
[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...
=20
[3] gdb output of a "module Main where main =3D 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>:=20
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=20
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 =3D (<text variable, no debug info> *) 0xc0f14 <GHCziTopHandler_runI=
O_entry>
(gdb) p &GHCziTopHandler_runIO_info
$2 =3D (<text variable, no debug info> *) 0xc0f12 <GHCziTopHandler_runI=
O_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=3D0x247090) at Schedule.c:2257
#4 0x001fcd44 in waitThread (tso=3D0x500c0000, ret=3D0x0) at Schedule.=
c:2214
#5 0x001fb6c8 in rts_mainEvalIO (p=3D0x226028, ret=3D0x0) at RtsAPI.c:=
489
#6 0x001fb084 in main (argc=3D1, argv=3D0xeffffd84) 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...
--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
iEYEARECAAYFAj1F7Q0ACgkQ6krNXPZcaM0ebwCfdu/Rt97k77XK9LYNXcWrHb0N
bzMAn3LEyg/nI8xUNK1JZKlhE2Cso+Gw
=fV5F
-----END PGP SIGNATURE-----
--PEIAKu/WMn1b1Hv9--