Jim, thank you--that makes alot of sense. I hadn't thought through the signal implications. And re-reading Reid's post, he does make it clear that the JIT-code injection is somehow a part of an interprocess communication.
The question then becomes, does the DNB.h protocol support the JIT-code injection, or if not, could that be a part of it? 1 - Modifying DNB.h to make sure it does all we need it to for all platforms 2 - Grab the code from within ProcessLinux and put it in a new DNB.cpp implementation for linux 3 - Make the ProcessLinux code us the DNB.h interface 4 - Reuse DNB.cpp/.h for linux in a new or modified version of "debugserver" Greg's outline sounds reasonable to me (added thoughts?), but I'd like to know if it advances the JIT-code injection objective. Thanks guys! Jason On Wed, Mar 16, 2011 at 1:36 PM, Jim Ingham <[email protected]> wrote: > An "in process" debugger in lldb would have to be a separate "Process" > plugin from the one that we would normally use on Mac OS X or Linux to get > around some bootstrapping problems, like for instance you can't ptrace > yourself so the standard method of taking control of a process wouldn't > work. Another example is that a breakpoint hit would be a real SIGTRAP > signal in your program, so you'd have to handle the SIGTRAP in a signal > handler and then generate a debugger event for it, rather than just getting > the SIGTRAP through ptrace or a mach exception or whatever. And if I sat > longer I bet I could come up with a bunch of other tricky bits you'd have to > handle. So it's clear that if you wanted to do an "in process" debugger in > LLDB you would have to do it as a separate type of process plugin. That > said, I can't think of any reasons off the top of my head why this wouldn't > work... > > Another problem is that, at present, lldb assumes that when the program is > being examined in the debugger, it is stopped altogether. You obviously > can't do that if you're in process. We plan to implement a "no stop" mode > where you would stop the thread that hit a breakpoint, say, but not the > other threads. But that's a ways off yet. You could probably fudge this by > having your "in process" process plugin know that stopping & restarting > actually means suspending & resuming some subset of the program's threads, > however. > > In sum, I don't think that "in process" debugging as you are suggesting is > impossible, but it would not fall out directly from the low level bits that > do "other process" debugging. It would require some separate effort. > > OTOH, I'm not quite clear why having the debugger in-process is essential > to your stated goals? What do you gain by having the process control parts > of the development environment be in the same process as the newly injected > code? The article you quoted is about injecting debug information along > with newly injected code. Having the debugger in process is not going to > remove that requirement, and conversely once it is there, the debugger > should be able to find it whether in process or not. > > Jim > > > > On Mar 16, 2011, at 11:00 AM, Jason E. Aten wrote: > > > To this end, I'm actually most interested in exploring the very un-remote > direction, where the debugger and the debuggee are as close as poosible, > even in the same process space (as would probably be necessary). The aim is > to get minimum re-compile times to support JIT-based everything, for an > incremental style development with JIT-support, and simultaneous access to > debugger level ability to step through the just JIT-ed code. The goal would > be to obtain something akin to the rapid LISP development environment with > hot-swappable functions, but rather than interpreted, have it be llvm > JIT-based. > > > > But perhaps my thoughts on adding this kind of feature to LLDB are not > realistic. If LLDB always needs its target process to be a separate process > (how baked in is that assumption, by the way, I guess that is really a key > and important question!?), then I may not be able to implement the > description above, inspired by Reid Kleckners post below. > >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
