And so it begins... (ghc-5.04 bootstrapped for sparc-unknown-linux)

Michael Weber
Tue, 30 Jul 2002 03:34:05 +0200

Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[In a hurry...]

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/

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:

			  !!! 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... ;)


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

    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

  * 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? =20

  * 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 =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=
    (gdb) p &GHCziTopHandler_runIO_info
    $2 =3D (<text variable, no debug info> *) 0xc0f12 <GHCziTopHandler_runI=
    (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.=
    #5  0x001fb6c8 in rts_mainEvalIO (p=3D0x226028, ret=3D0x0) at RtsAPI.c:=
    #6  0x001fb084 in main (argc=3D1, argv=3D0xeffffd84) at Main.c:106

[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...

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.0.6 (GNU/Linux)