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
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
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
Excellent, those suggestions are along the lines I was thinking.
Thanks for the pointer (no pun intended) re. the C functions in the
RTS; I hadn't known of those.
Will
On Wed, Apr 20, 2011 at 6:22 AM, Simon Marlow
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
participants (3)
-
Edward Z. Yang -
Simon Marlow -
William Knop