[lldb-dev] lldb -- architecture level question -- linux v. darwin
Jason E. Aten
j.e.aten at gmail.com
Wed Mar 16 11:52:13 PDT 2011
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.
On Wed, Mar 16, 2011 at 1:36 PM, Jim Ingham <jingham at apple.com> 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
> 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,
> 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.
> 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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev