[lldb-dev] lldb -- architecture level question -- linux v. darwin

[Jason E. Aten]

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 <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
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20110316/a81981a3/attachment.html>