MacOS X GHC Status

[Simon Marlow]

> Some programs work, including green-card and some HOpenGL programs.
>=20
> GHC, compiled with my registerized version, crashes.
> At some point, there is pointer on the Stg Stack that points=20
> into data space.
> However, it doesn't point to a closure. In points to a place just=20
> after the last data symbol in of one GHC module, and before the next=20
> (there's quite some stuff between those two modules, and I have no=20
> idea what the linker puts there).
> The word at that position is definitely not a valid info pointer, it=20
> points about 300 megabytes above the heap (into unmapped space).
> MacOS X doesn't yet support watchpoints, so I still have no idea=20
> "who" put this strange pointer onto the stack. Under what conditions=20
> are pointers into data space
> put on the stack? Any ideas how I could go about debugging this? How=20
> can I possibly ever find out what code is putting this nonsense value=20
> on the stack?

These things are particularly tedious to debug (or fun and rewarding,
depending on your particular inclinations :-).  The first thing to do is
compile the RTS with debugging support: there are two lines to copy from
config.mk into your build.mk, namely the settings for GhcRtsHcOpts and
GhcRtsCcOpts.

When you have this, you can turn on heap sanity checking with -D128,
which occasionally finds bugs closer to the point at which they occur.
In particular if there's a bug in GC it'll probably show up right after
the GC in which it occurs, rather than later on during execution.

The only pointers into data space that should be on the stack are
pointers to static closures.  The other things on the stack are pointers
to text space (info tables), and pointers into heap space (dynamic
closures).

> For now, I'll try to find some smaller programs that crash, too.

Yes, that's a good idea.  I usually make sure the whole nofib suite goes
through before attempting to bootstrap a compiler.

Cheers,
	Simon