On 2 Aug 2014, at 02:10, Lang Hames <lha...@gmail.com> wrote: > (2) Is there a canonical way for the debugger to communicate to a JIT that > it's interested in inspecting the JIT's output? If we're going to use > breakpoints (or something like that) to signal to the debugger when objects > have been linked, is it reasonable to have an API that the debugger can call > in to to request the information it's looking for? If the JIT actually > receives a call then it would give us a chance to lazily populate the > necessary data structures.
The problem with calling into the JIT is that it's very common to debug a program that contains bugs. If it contains bugs, then it's likely to be in an undefined state when the debugger is attached. We've all seen gdb and lldb hit signals when executing code in the debugged process because they hit some invalid memory and have to give up on something typed in the command line. It's even worse if you have to invoke the JIT. Any memory-management errors in JIT'd code have the potential to break the JIT and so break its ability to provide the debug info (which is another reason why it's good to have the debug info be read-only). This is not an issue if your deployment model is to JIT the code in one process and run it in another. MCJIT was designed to allow this, and it might be a good idea to encourage this usage pattern, but it's not always feasible. It should be possible to have the debugger toggle a variable when it's attached and inspecting a particular piece of code, to allow the JIT to unload debug info later. I'm somewhat hesitant to recommend even that, because perturbing the memory layout depending on whether the debugger is attached is likely to cause heisenbugs. I wonder if a better solution is to stream the debug info somewhere - to a pipe or a file that a debugger can be responsible for managing. Set an environment variable before you launch the process to tell it either 'write debug info to this file' or 'write debug info to file descriptor number N'. If this isn't set, don't bother generating debug info. If it is, send debug info there. If it's a pipe with the debugger on the other end, then the debugger gets a message as soon as there's more debug info to read and can discard any of the information that it doesn't care about. David _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
