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
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
