[lldb-dev] [LLVMdev] MCJIT debugger registration interface.

[Kevin Modzelewski]

On Sun, Aug 10, 2014 at 3:37 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>
> I agree. I suspect that a better solution is to have the smarts for
> grokking the debug data inside LLVM, possibly borrowing logic from lldb.
> For starters clients like WebKit will want a machine-offset-to-debug-info
> map, which ain't rocket science - but currently parsing dwarf inside the
> LLVM client is the only way to do this afaict.
>

I think what you're asking for is currently available in the C++ API: I'm
not familiar with the C API, but my guess is a lack of a JITEventListener
equivalent is what's caused you guys to do some contortions using the
memory manager to inspect the MCJIT output (I think this also applies to
finding the stackmaps sections).

So far our use of debug info is limited (only for user tracebacks) but
we've been pretty happy with using a JITEventListener to call
DIContext::getDWARFContext on the output, which at least for line table
information, provides DWARF-parsing for us.  I guess it's inelegant to
re-parse the data that was just generated, but so far it seems fine.
https://github.com/dropbox/pyston/blob/master/src/codegen/unwinding.cpp#L111


> Clients of optimizing JIT compilers are usually going to want to have some
> finer-grained control over how that JIT presents debug data to the
> debugger. Probably all that we want is: the JIT offers its debug data to
> its client, and the client decides if, and how, this data is presented to
> any debugger (lldb, gdb, or whatever). A reasonable default can of course
> be provided, if it leads to a good API.
>
> The MCJIT is currently ill suited to this kind of thing because it
> pretends to be a black box execution engine for LLVM IR. This black box
> then makes further assumptions that make sense for programs that target the
> C runtime. I believe that life would be easier if the task of generating
> code and the task of linking and executing it were better separated in the
> API.


My impression is that the builtin gdb registration is just the default way
of consuming the debug information -- I agree that the default behavior
shouldn't come at the cost of flexibility for users who need something more
customized, but it seems like things are close to the point that the
GDB-registrar could be built using the C++ API, and it sounds like Lang's
proposed changes would make it more possible.  The situation sounds
different with the C API, but I think that might be an orthogonal issue of
C-api-vs-C++-api, rather than MCJIT-internals-vs-api?

Personally I find the default gdb registration to be helpful in debugging
of the JIT itself, even if it's not related to the task of providing our
language-specific debug functionality.  Maybe one thing that would be nice
to have is an API for disabling the GDB registration for performance
reasons, which we would potentially make use of in release builds.  I'm not
sure how much that would actually save, though, since I would assume the
registration cost is dwarfed (pun intended?) by the compile time.

kmod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140811/2e001296/attachment.html>