Debugging Haskell: the stack

[Simon Marlow]

> when I call from Haskell into C, stop it there, and use a=20
> debugger (e.g=20
> gdb) to look at the stack, it looks all broken. Here is an example:
>=20
> #0  c_init () at c.c:5
> #1  0x08048f14 in ssM_fast1 ()
> #2  0x0804a248 in sakt_ret ()
> #3  0x04c58308 in ?? ()
>=20
> (c_init is a C function on which I've set a breakpoint). Now, I don't=20
> expect to see meaningful stack frames from Haskell, but I am calling=20
> into Haskell from C, and I would expect the C functions calling into=20
> Haskell to appear on the stack frame. What is happening? How does=20
> Haskell manage to still return to C when the stack looks like that?

GHC's runtime system leaves a hole on the C stack to use for temporary
storage while running Haskell code, and then it doesn't move the C stack
pointer at all until calling out to C or returning to the runtime.  Gdb
won't be able to traverse the hole to find the enclosing stack frames.

Cheers,
	Simon