July 2002 - Glasgow-haskell-users

question about RealWorld and realWorld#
by Bernard James POPE 31 Jul '02

31 Jul '02

Hi all, Am I right in saying that the type constructor RealWorld is special to the compiler in that it is not defined in any Haskell code but wired in? ie this is its only definition in ghc (ghc/compiler/prelude/TysPrim.lhs): realWorldTyCon = mkLiftedPrimTyCon realWorldTyConName liftedTypeKind 0 [] PrimPtrRep realWorldTy = mkTyConTy realWorldTyCon It seems to be visible throughout the compiler but I can't find anywhere that explicitly exports it. I think the comment in TysPrim.lhs probably answers my question, but I'm not 100% sure. Am I also correct is saying that the identifier realWorld# is similar in that it isn't defined in any Haskell code, but is primitive to the compiler? I would have expected to find something like: realWorld# :: State# s realWorld# = undefined My instinctive feeling is that GHC treats State# objects specially, so that they only live at compile time but are not present at runtime. This is mentioned in the "Lazy functional state threads" paper: "By the time the program reaches the code generator, the role of the state values is over, and the code generator arranges to generate no code at all to move around values of type State#" (page 13 in my version of the paper). The reason I ask is that things have changed somewhat since that paper was written and I wanted to be absolutely sure about the details in the current compiler. I must admit that I always found runST a little weird in that is somehow manages to conjure up an initial state for me. I now see how it does it. Cheers, Bernie.

1 0

RE: And so it begins... (ghc-5.04 bootstrapped for sparc-unknown-linux)
by Simon Marlow 30 Jul '02

30 Jul '02

> 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]% WOOHOO!!! Impressive stuff, congrats 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... ;)), You'll be glad to know that all going according to plan, we'll be able to remove this dependency from the RTS before too long. We're planning some changes to the tail-call mechanism that means stack-walking will no longer need to be able to distinguish between code and data pointers. > * make bootstrapping work with uh... less hand-waving, > praying/swearing in the general direction of Glasgow, etc. ;) We're definitely interested in doing this. BTW, swearing at Glasgow won't get you very far, since we're in Cambridge :-p Cheers, Simon

1 0

And so it begins... (ghc-5.04 bootstrapped for sparc-unknown-linux)
by Michael Weber 29 Jul '02

29 Jul '02

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

1 0

RE: FFI - closure, __stginit
by Simon Marlow 29 Jul '02

29 Jul '02

> I'm just trying the ffi - importing some Haskell function > into C. I've got a > module "HelloWorld" with an exported function "add". And I got this > "undefined reference" error while linking: > > undefined reference to `HelloWorld_zdfadd_closure' > > Can anybody please help me, what's wrong here? > > A second problem is the __stginit... function. I've defined > void __stginit_HelloWorld (void) {} > with an empty body. Is this o.k.? Or should I make ghc to > generate it for me > somehow? It sounds like you're not linking the Haskell module into the binary. The compiled Haskell code should provide both HelloWorld_zdfadd_closure and __stginit_HelloWorld. Cheers, Simon

1 0

FFI - closure, __stginit
by Ondrej Rypacek 29 Jul '02

29 Jul '02

Hi, I'm just trying the ffi - importing some Haskell function into C. I've got a module "HelloWorld" with an exported function "add". And I got this "undefined reference" error while linking: undefined reference to `HelloWorld_zdfadd_closure' Can anybody please help me, what's wrong here? A second problem is the __stginit... function. I've defined void __stginit_HelloWorld (void) {} with an empty body. Is this o.k.? Or should I make ghc to generate it for me somehow? Thanks a lot, Ondra

1 0

RE: suggestion regarding :browse
by Simon Peyton-Jones 29 Jul '02

29 Jul '02

| :browse Some.Long.Module.Name | | but not | | :browse N | | which would be really nice :P | | if this could make its way into 5.04.1, that would be wonderful It turns out that the impl isn't structured with a separate modulename->modulename mapping so it would not be simple to implement. For example, what if two modules whose top level scopes you have open use the same abbreviation for a different module. Yes, we could arrange to emit an ambiguous-ref message, but it's all work. So I'm not enthusiastic, I'm afraid. Simon

1 0

Module Set
by Christian Maeder 28 Jul '02

28 Jul '02

Hi, I think the module Set lacks at least a (partial) function minimum :: forall a. (Ord a) => Set a -> a because "setToList" is the only (though sufficient) function to access the elements of a list. Will "minimum = head . setToList" be correct or do I need to sort the list? I was considering using sorted lists directly, but I thought the functions `elem` and `union` are not as efficient as they could be (under the assumption that the input lists are sorted). Surely balanced trees will be better for large sets. Besides the minimum, also the maximum or the simultaneous splitting of a set into its minimum and the remaining set would be useful (for recursions). Cheers Christian

2 5

RE: Problems dealing with GHC incompatibilities
by Simon Marlow 26 Jul '02

26 Jul '02

> What version of GHC do you use at Microsoft? Do you have a > last-not-broken version > which you use for developing GHC or what? If there is a > last-not-broken version it would > be good to have access to it. We generally have 'ghc' pointing to the latest stable release (i.e. now it points to 5.04), and I usually install a snapshot whenever we make one. We don't develop day-to-day using snapshots, because switching over existing builds is a little annoying. > For quite a long time I ran an automated system which > compiled GHC every night from > CVS (using the previous version) and installed it on our > system if the compile completed. This > actually worked quite well, though I stopped doing it because > the compilation system got > more complicated, I had problems doing it on Sparc/Solaris, > and it was too much trouble. > If the compile finished it was unusual for the compiler > itself to be hopelessly broken; > to be on the safe side you could check it was able to compile > Happy and Haddock. Something > like this might be good. Of course it would have to be made > very clear that such snapshot > releases were for evaluation only, and that only the official > releases were to be relied on. Our nightly builds run a 3-stage bootstrap and then the whole test suite, so you usually have a pretty good idea by the end whether the compiler is a good 'un or not. You can checkout the scripts we use for the nightly builds from CVS: just 'cvs co nightly'. Setting up your own build using these scripts is fairly painless; Malcolm Wallace did it recently for Sparc to bolster our Sparc support a bit. Cheers, Simon

2 1

RE: Problems dealing with GHC incompatibilities
by Simon Marlow 26 Jul '02

26 Jul '02

> So my suggestion is that > (1) The GHC team continue to issue snapshot releases as often > as possible (I don't know why they > don't make the automatic builds generate them every night). We could, and in fact the nightly build system has support for publishing the resulting source & binary bundles. One consideration, though, is that someone pulling down a snapshot will want a clue as to whether that snapshot is likely to be not completely broken, and without reading cvs-ghc(a)haskell.org. So we tend to pick snapshots at moments when we know things are in a reasonably stable state. > By the way, Simon M, how long can we rely on the hslibs > library structure? Because some time > I shall have to schedule time to move over to the new > structure, and I'm not looking forward to > it. Perhaps they'll go away in 6.00... how do people feel about that? The 5.04 release will continue to be supported up until the release of 6.00, which is likely to be at least 6 months (probably longer). Cheers, Simon

2 1

Problems dealing with GHC incompatibilities 2
by George Russell 26 Jul '02

26 Jul '02

Simon M wrote [snip] > If you don't want things to change, don't upgrade! [snip] A typical Microsoft response, if I may say so. : -) Admittedly we don't have the problem that the penalty for not upgrading GHC is that you expose your computer to every Bugtraq-reader on the Internet. All the same, you have to upgrade now and again, or cut yourself off from all bug fixes, improvements, and so on. Putting off unpleasant upgrades just makes the bit rot ten times harder to deal with when you do deal with it.

1 0