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.<div>
<br></div><div>The question then becomes, does the DNB.h protocol support the JIT-code injection, or if not, could that be a part of it?</div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br>
</span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br>1 - Modifying DNB.h to make sure it does all we need it to for all platforms<br>
2 - Grab the code from within ProcessLinux and put it in a new DNB.cpp implementation for linux<br>3 - Make the ProcessLinux code us the DNB.h interface<br>4 - Reuse DNB.cpp/.h for linux in a new or modified version of "debugserver"</span><br>
<div><div><br></div><div>Greg's outline sounds reasonable to me (added thoughts?), but I'd like to know if it advances the JIT-code injection objective.</div><div><br></div><div>Thanks guys!</div><div><br></div><div>
Jason</div><div><br><div class="gmail_quote">On Wed, Mar 16, 2011 at 1:36 PM, Jim Ingham <span dir="ltr"><<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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...<br>


<br>
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.<br>


<br>
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.<br>


<br>
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.<br>


<font color="#888888"><br>
Jim<br>
</font><div><div></div><div><br>
<br>
<br>
On Mar 16, 2011, at 11:00 AM, Jason E. Aten wrote:<br>
<br>
> 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.<br>


><br>
> 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.<br>


<br>
</div></div></blockquote></div><br><br>
</div>
</div></div>