GHC/LLDB integration

William Knop william.knop.nospam at gmail.com
Mon Apr 18 19:50:03 CEST 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



More information about the Glasgow-haskell-users mailing list