Thank you Greg for the detailed reply. I read it with great interest.<div><br></div><div>The main thing that got me interested in LLDB in the first place was the potential to be able to (add the capability to) JIT-up code from the command line, and inject that new code into a running process (after going through the Kaleidoscope tutorial and reading the post (quoted below) from Reid Kleckner). </div>
<div><br></div><div>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>
<div><div><br></div><div>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><meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="color: rgb(102, 102, 102); font-size: 13px; "><div style="background-color: transparent; "><a href="http://www.google.com/url?q=http%3A%2F%2Fllvm.org%2Fdocs%2FDebuggingJITedCode.html&sa=D&sntz=1&usg=AFrqEzcbHWnFcjte7dRGV3tmIzxDy94UdQ" style="color: rgb(51, 102, 153) !important; ">http://llvm.org/docs/DebuggingJITedCode.html</a></div>
<div style="background-color: transparent; "><br></div><div style="background-color: transparent; "><span style="font-weight: bold; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-size: medium; ">Written by Reid Kleckner</span></div>
<div style="background-color: transparent; "><br></div><div style="background-color: transparent; "><div style="background-color: transparent; ">Background</div><div style="background-color: transparent; "><br></div><div style="background-color: transparent; ">
Without special runtime support, debugging dynamically generated code with GDB (as well as most debuggers) can be quite painful. Debuggers generally read debug information from the object file of the code, but for JITed code, there is no such file to look for.</div>
<div style="background-color: transparent; "><br></div><div style="background-color: transparent; ">Depending on the architecture, this can impact the debugging experience in different ways. For example, on most 32-bit x86 architectures, you can simply compile with -fno-omit-frame-pointer for GCC and -disable-fp-elim for LLVM. When GDB creates a backtrace, it can properly unwind the stack, but the stack frames owned by JITed code have ??'s instead of the appropriate symbol name. However, on Linux x86_64 in particular, GDB relies on the DWARF call frame address (CFA) debug information to unwind the stack, so even if you compile your program to leave the frame pointer untouched, GDB will usually be unable to unwind the stack past any JITed code stack frames.</div>
<div style="background-color: transparent; "><br></div><div style="background-color: transparent; ">In order to communicate the necessary debug info to GDB, an interface for registering JITed code with debuggers has been designed and implemented for GDB and LLVM. At a high level, <span style="background-color: rgb(255, 255, 0); "><i>whenever LLVM generates new machine code, it also generates an object file in memory containing the debug information. LLVM then adds the object file to the global list of object files and calls a special function </i><b>(__jit_debug_register_code)</b><i> marked noinline that GDB knows about. When GDB attaches to a process, it puts a breakpoint in this function and loads all of the object files in the global list. When LLVM calls the registration function, GDB catches the breakpoint signal, loads the new object file from LLVM's memory, and resumes the execution. In this way, GDB can get the necessary debug information.</i></span></div>
<div style="background-color: transparent; "><br></div><div style="background-color: transparent; ">At the time of this writing, LLVM only supports architectures that use ELF object files and it only generates symbols and DWARF CFA information. However, it would be easy to add more information to the object file, so we don't need to coordinate with GDB to get better debug information.</div>
</div></span></div><div><br><div class="gmail_quote">On Wed, Mar 16, 2011 at 12:40 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
See my other reply to the previous thread on this subject.<br>
<br>
To quickly summarize why we use debugserver on macosx:<br>
- If we are always debugging remotely even when debugging locally, adding remote debugging for MacOSX comes for free and we don't need to test local vs remote debugging.<br>
- Having a separate process be the parent of an inferior process helps to isolate the "lldb" binary from bad things<br>
<div><div></div><div class="h5"><br>
<br>
<br>
<br>
On Mar 16, 2011, at 10:14 AM, Jason E. Aten wrote:<br>
<br>
> Dear Steve and lldb-dev,<br>
><br>
> (starting a new thread to give a better, more appropriate, thread title)<br>
><br>
> I've investigated a little bit more and I am coming to understand there is a big difference at the moment in how lldb initiates target processes in darwin vs linux (see the comparative ps output details below). Perhaps it is more direct on linux in order to avoid having to port the debugserver?<br>
><br>
> Any insight into plans for lldb on linux would be appreciated. I do see there are significant architectural differences at the moment, in that lldb on darwin goes through the debugserver process. I wonder if that is intended as a temporary quick fix, or done with an eye to simplification. e.g. I don't know, but perhaps it is much simpler to ptrace directly on linux than to use a separate process? I'm pretty clueless here, and just starting to explore lldb on linux, so feel free to point me towards background threads or information I might wish to review.<br>
><br>
> Thanks everyone!<br>
><br>
> cheers,<br>
> Jason<br>
><br>
><br>
> details:<br>
><br>
> ### On darwin, lldb starts a debugserver child process, and debugserver in turn starts a child process to contain the debug target a.out.<br>
><br>
> UID PID PPID<br>
> bash<br>
> |<br>
> V<br>
> 2086 42103 22537 0 0:00.07 ttyp0 0:00.16 ../lldb a.out<br>
> |<br>
> V<br>
> 2086 42104 42103 0 0:00.01 ?? 0:00.02 /Users/jaten/pkg/llvm+lldb+ldc/llvm-2.8/tools/lldb/build/Debug/LLDB.framework/Versions/A/Resources/debugserver localhost:11358 --native-regs --setsid<br>
> |<br>
> V<br>
> 2086 42105 42104 0 0:00.00 ?? 0:00.00 /Users/jaten/pkg/llvm+lldb+ldc/llvm-2.8/tools/lldb/build/Debug/test-lldb/a.out<br>
><br>
><br>
> ### On linux, at the moment, what I see in contrast is that lldb is the direct parent of the debug target (a.out here).<br>
><br>
> jaten 4532 0.0 0.3 25752 8160 pts/3 Ss 03:59 0:01 | \_ /bin/bash --noediting -i<br>
> jaten 22645 0.6 0.8 148260 18256 pts/3 Sl+ 11:57 0:00 | | \_ ./lldb test-lldb/a.out<br>
> jaten 22650 0.0 0.0 11728 960 pts/11 Ts+ 11:58 0:00 | | \_ /home/jaten/pkg/latest-svn-llvm/llvm-build-r127600-with-lldb/Release+Debug+Profile+Asserts/bin/test-lldb/a.out<br>
><br>
><br>
> On Wed, Mar 16, 2011 at 9:40 AM, Jason E. Aten <<a href="mailto:j.e.aten@gmail.com">j.e.aten@gmail.com</a>> wrote:<br>
> On Mon, Mar 14, 2011 at 11:11 PM, Stephen Wilson <<a href="mailto:wilsons@start.ca">wilsons@start.ca</a>> wrote:<br>
> Well, in a nutshell you would need to implement something similar to<br>
> what ProcessLinux::DoLaunch does, but in this case you want things to<br>
> boil down to a ptrace(ATTACH) instead of a fork() + ptrace(TRACEME).<br>
> The basic sketch would be:<br>
> - Define a new ProcessMonitor ctor that takes a pid as argument.<br>
> - Define ProcessMonitor::Attach which does the actual ptrace magic.<br>
> - Write a another StartOperationThread method that takes a (new)<br>
> AttachArgs struct as argument (could just contain the pid for now)<br>
> and sets up the monitoring business in essentially the same way as<br>
> the current launch-based code does. Probably rename<br>
> OperationThread to LaunchOpThread or similar and write your own<br>
> AttachOpThread analog.<br>
> It would certainly be nice to have that implemented. I do not see<br>
> anything that would cause any complications off hand, and it should<br>
> remain fairly isolated from all the other work that needs to happen wrt<br>
> linux support.<br>
><br>
><br>
> Thanks Steve! I scoped out the work a little bit, mostly by stepping through in the debuggers both the Xcode version and the current Linux version. Btw it looks like the current version of lldb has been incremented (now r127600), which is very good news.<br>
><br>
> I note that the main contrast is this: the darwin built lldb uses the ProcessGDBRemote class, implemented in the "llvm/tools/lldb/source/Plugins/Process/gdb-remote" directory, rather than ProcessLinux.<br>
><br>
> The curious thing is: when I look through the gdb-remote code, there are only two lines that are #ifdef APPLE. It seems fairly reusable.<br>
><br>
> My naive question then is, why not just reuse the ProcessGDBRemote code for Linux as well? There's probably higher level design issues that I'm not familiar with, so anyone on lldb-dev should feel free to chime in here. The second lazy inclination is to just port that code to linux if it must go in it's own directory.<br>
><br>
> Let me know what you think. I'm probably asking silly questions, but I'm just trying to get my bearings. Please bear with me! :-)<br>
><br>
> Thanks,<br>
> Jason<br>
><br>
> p.s. the one thing that kept me from trying this directly was figuring out where in the Makefile system this got chosen, because by default on linux, the gdb-remote directory isn't built. If anyone knows where this controlled, please point it out. Thank you!<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Jason E. Aten, Ph.D.<br><br><br>
</div></div></div>