Hello William, You can find "the state of the art" (which isn't very advanced :-) in debugging GHC compiled code with GDB here: http://hackage.haskell.org/trac/ghc/wiki/Debugging/CompiledCode Maybe others can give more specific advice. Cheers, Edward Excerpts from William Knop's message of Mon Apr 18 13:50:03 -0400 2011:
Hello all, I've been using LLDB for a few weeks now, initially acquainting myself with its python bindings. It occurred to me early on that they might integrate into GHC's testsuite well, so I began writing a driver. The idea was to encapsulate the launched haskell processes in LLDB and generate more useful debugging information for failed tests (I'd previously been hunting down a few spurious segfaults). However, LLDB is quite immature and currently lacking such capabilities as generating core files, among other things.
But while searching for core file generation, I ended up discovering that it is to eventually be implemented as a native plugin. It turns out that the plugin system allows for a lot of extensibility, including language and ABI extension. So I started digging into that and just recently began working on adding a GHRuntime plugin which should allow for demangling of symbols (easy), analysis and description of info tables and call graphs (hard), etc.
So before I get too far into it, and because I am not a GHC guru, I'd like to gauge it's ultimate usefulness amongst the community. Given that haskell code goes through several stages of transformation, can more useful information be derived from a debugged executable? Or can more useful debug information be emitted by GHC if it can be interpreted by a purpose-made debugger plugin? If so, what information and functionality would be desirable? Ideas and comments are most welcome.
Will