GHC/LLDB integration

[Edward Z. Yang]

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
>