[lldb-dev] Debugging JIT-compiled code with LLVM

[Greg Clayton]

The main issue is that there is no central place right now where JIT'ed code is registered that allows anyone to register newly generated code that would be known to debuggers. I know the current dyld has some way to add JIT's code to its all_image_infos structure, but none of our debuggers use this, so even if you did add your jitted code to this structure, no darwin debuggers would currently see this anyway. 

I beleive that GDB has some hooks for loading JIT'ed ELF .o files on the fly, but I don't believe this is implemented for mach-o .o files on MacOSX.

LLDB currently doesn't yet have any support for JIT'ed code, though I would be happy to work with you if you wanted to get that working in LLDB.

Greg Clayton



On Nov 17, 2010, at 8:32 AM, Simon Ask Ulsnes wrote:

> Hey list,
> 
> I know similar questions have been asked before, but I have been
> unable to find a clear answer to what approach would be recommended
> for this use case (the LLDB documentation is sparse, to put it
> generously).
> 
> My situation: The scripting language is JIT-compiled by LLVM. As is
> the language runtime, written in C and precompiled to bitcode with
> Clang. The runtime is hosted by a driver application that loads and
> initializes LLVM, then hands over responsibilities to the runtime.
> 
> Currently, this is hard to debug, because neither gdb nor LLDB seem to
> know about the symbols and debug information emitted by the JIT
> compiler. The driver application sets llvm::JITEmitDebugInfo = true at
> launch.
> 
> According to the LLVM documentation, gdb 7.0 and later should support
> debugging of JIT'ed code, but this does not appear to be true
> (backtraces from JIT'ed functions are nonsensical, the eh_frame looks
> wrong, and of course breakpoints don't work). What surprises me is
> that LLDB doesn't seem to catch the JIT'ed debug information either.
> 
> The previously proposed solution of compiling code to dylibs and using
> dlopen()/dladdr() to call functions, instead of using the on-the-fly
> JIT compiler in LLVM, is not only pretty inconvenient, it's also
> incorrect, since my code and language takes advantage of quite a few
> opportunities for run-time-optimization (and so the code used for
> debugging would poorly reflect the actual code).
> 
> I have been attaching LLDB/gdb to the main driver executable, but
> perhaps this is the wrong way to go — would it be more advisable to
> host the debugger within my own driver process using LLDB.framework?
> 
> Please advise. :-)
> 
> Platform: Mac OS X 10.6.5, GCC 4.5, gdb 7.1, LLVM 2.8, LLDB from SVN trunk.
> 
> Sincerely,
> Simon
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev