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