GHC/LLDB integration

[Simon Marlow]

On 18/04/2011 18:50, William Knop wrote:
> 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.

Sounds interesting, though I know nothing about LLDB.  It would be nice 
to have a little help from the debugger for things like:

  - displaying the stack in a nicer way
  - displaying heap objects
  - searching the heap
  - displaying runtime state: what threads exist and what state
    they're in, summary of various RTS data structures, etc.

For some of these I have C functions in the RTS that I can call from 
gdb.  e.g. there's findPtr() that searches the heap for occurrences of a 
particular pointer (useful for debugging leaks when the higher level 
tools don't give you enough information).

Cheers,
	Simon