GHCi doesn't work unregisterised

[trentbuck@…]

To reproduce this bug, write the following text to bug.hs.

data D = D Char deriving Show                                                                                                                                                                           
main = print f                                                                                                                                                                                          
f = D 'a'                                                                                                                                                                                               

Start ghci, and at the prompt enter :load bug.hs, then f. Instead of printing D 'a', GHCi will segfault.

• This bug DOES manifest on PowerPC (running Debian/sid).
• This bug DOES NOT manifest on i386 (running Debian/sid).
• This bug DOES manifest when bug.hs is loaded in ghci.
• This bug DOES NOT manifest when bug.hs is compiled with ghc.

[desrt]

this appears to be a problem with the debian packaging.

when i run ghci as provided by ubuntu breezy i get the segfault.

when i run my own self-rolled ghci on the exact same machine, there is no problem at all.

[simonmar]

Who is actually responsible for the Debian packaging of GHC on powerpc/Linux? Any takers?

[simonmar]

Ian Lynagh says he'll look into this, as soon as make is fixed in Debian:

 https://savannah.gnu.org/bugs/?func=detailitem&item_id=15584  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346248

[simonpj]

[I'm adding this comment on behalf of Ian, who couldn't for some reason.]

On Thu, Mar 02, 2006 at 12:28:48PM +0000, Simon Marlow wrote:

> Ian Lynagh wrote:
> 
> >Currently I have this for most arches:
> >
> >    echo "GhcUnregisterised=YES" >> mk/build.mk
> >    echo "SplitObjs=NO" >> mk/build.mk
> >
> >I'll add
> >
> >    echo "GhcWithNativeCodeGen=NO" >> mk/build.mk
> >
> >Is there anything else you'd recommend?
> 
> Does GHCi work on an unregisterised build?  If it does, I'm pleasantly 
> surprised :-)  If not, you probably want GhcWithInterpreter=NO too.

It doesn't seem to entirely not work, e.g. things like

    map Char.ord "foo"

are fine, but it also doesn't entirely work, e.g. bug #631.

With

   echo "GhcUnregisterised=YES" >> mk/build.mk
   echo "GhcWithNativeCodeGen=NO" >> mk/build.mk
   echo "SplitObjs=NO" >> mk/build.mk

on a powerpc:

igloo@bruckner:~$ ghci bug.hs
[...]
Compiling Main             ( bug.hs, interpreted )
Ok, modules loaded: Main.
*Main> f
Segmentation fault
igloo@bruckner:~$ ghci bug.hs 
[...]
Compiling Main             ( bug.hs, interpreted )
Ok, modules loaded: Main.
*Main> map Char.ord "foo"
[102,111,111]
*Main> print (D 'a')
<interactive>: internal error: scavenge_one: strange object 32137
    Please report this as a bug to glasgow-haskell-bugs@haskell.org,
    or http://www.sourceforge.net/projects/ghc/
igloo@bruckner:~$

and on a sparc:

igloo@vore:~$ ghci bug.hs
[...]
Compiling Main             ( bug.hs, interpreted )
Ok, modules loaded: Main.
*Main> f
Bus error
igloo@vore:~$ ghci bug.hs
[...]
Compiling Main             ( bug.hs, interpreted )
Ok, modules loaded: Main.
*Main> map Char.ord "foo"
[102,111,111] 
*Main> print (D 'a')
<interactive>: internal error: scavenge_one: strange object 33216
    Please report this as a bug to glasgow-haskell-bugs@haskell.org,
    or http://www.sourceforge.net/projects/ghc/
igloo@vore:~$ 

I haven't tried on x86/amd64 with the above build.mk. Is this something you'll look into fixing, or should I just drop ghci too?

Thanks Ian

[simonmar]

Interesting, it looks like it almost works. Do you know if the bug is restricted to PowerPC, or does it happen with other unregisterised builds? If it just depends on unreg, I can probably reproduce and look into it.

[igloo]

I have a fix for this particular problem (we were generating info tables for tables-next-to-code, which we don't have when unregisterised). There are still some test failures that don't happen when registerised that I have to look in to, though.

[igloo]

The failures turn out to mostly be FFI-related. Might be worth investigating 793 before looking further at this.

[igloo]

Punting on this

[Isaac Dupree]

A number of things rely on ghci (some humans, runghc(runhaskell)...) and it would be nice to have those reliably working even on the architectures where it often isn't (or can't be?) built registerised at any given moment. (Debian would still have to change its packaging to not disable GHCI on the architectures where it chooses to build unregisterised, once this works...)

[simonmar]

I'm taking this: the remaining issue is only that GHCi does not support FFI when compiled unregisterised, which will be fixed by #793.

[simonmar]

In theory this should be working now (libffi was imported). In practice, the tests appear to be failing in the unreg nightly build, so I need to figure out what's going on there.

[simonmar]

Now fixed; I have an unregisterised build on x86_64/Linux with a completely working GHCi, including FFI (using libffi) and debugger. The final fix was:

Mon Jul 28 08:56:21 PDT 2008  Simon Marlow <marlowsd@gmail.com>
  * Change the calling conventions for unboxed tuples slightly
  When returning an unboxed tuple with a single non-void component, we
  now use the same calling convention as for returning a value of the
  same type as that component.  This means that the return convention
  for IO now doesn't vary depending on the platform, which make some
  parts of the RTS simpler, and fixes a problem I was having with making
  the FFI work in unregisterised GHCi (the byte-code compiler makes
  some assumptions about calling conventions to keep things simple).