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 [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
