GHC (Haskell) lldb `Language` support starting point


I’m interested in learning what would be required to add GHC’s Haskell support to lldb in a nice way.
GHC has support for outputting some DWARF information. I would be interested in extending this, and integrating such extensions with lldb so that it could be used to reasonably debug a Haskell executable. Currently things like source-mapping work relatively well, but variable names are all mangled when setting breakpoints, (requiring knowledge of the mangling/demangling scheme to really get work done) and local scopes cannot be examined like a C-like-language would be due to the fun tricks GHC does when generating code (but I’m hoping this information can be encoded in DWARF somehow).

I have been browsing the documentation for lldb_private, and located (for example) [the Language class]( If I wanted to add a plugin to enable nice Haskell name demangling etc, I assume this would be the place to start. If this assumption is incorrect, please let me know!

I have a list of questions, and maybe I should break these off into separate posts, but I didn’t want to make a whole lot of noise all at once to start. Please forgive me if this is not the preferred way.

  1. If I were to create a GHCHaskellLanguage (Like [CPlusPlusLanguage](, would I be able to distribute this “plugin” outside of lldb? I ask because I don’t want to maintain a fork of lldb, and am somewhat intimidated by the idea of attempting to merge a (relatively) marginal language back into mainline lldb right away, so it would be nice if I could just maintain the plugin itself and distribute it through regular Haskell channels (somehow), at least at first.
  • If “yes” to the above, would users wanting to use it have to compile it themselves? Compile it and lldb themselves? Compile it a special way? Compile it in a way that is compatible with lldb somehow? Only use clang++ to compile it? I am somewhat familiar with C++, but my understanding is that C++ ABIs are relatively unstable, especially since this is in the lldb_private namespace of lldb. This isn’t a deal breaker, I just kind of need to know.
  1. If I needed interactive help from people who know more about lldb than I do, where would I request such help? I assume there is some IRC-like channel dedicated to more lldb-related discussion, but I’m not sure where to find it…

  2. GHC has an idiosyncratic name-mangling scheme. I would like to enable users of lldb to be able to set lldb breakpoints on what I’ll call the source name (unmangled) of a function, for example. Does lldb support this out-of-the-box, presuming you provide a Language impl that tells it how to demangle names, or would this be a larger undertaking/scripting challenge?

  3. Any super secret (or not so secret) hints at how to implement a new language for lldb would be appreciated!

  4. Does lldb support invoking an external process to attach to the debugger in programmable circumstances? GHC has an interactive debugger (that sort of works sometimes), and it would be nice to be able to drop you to a REPL if you need to, while still having the power and portability of an lldb-based debugger. (Exactly how to do this would be complicated and need more thought probably, but I just wanted to know if the skeleton of such functionality exists as of yet, as a starting point.)

I have other questions, but these are enough to get me started.