See my other reply to the previous thread on this subject. To quickly summarize why we use debugserver on macosx: - 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. - Having a separate process be the parent of an inferior process helps to isolate the "lldb" binary from bad things
On Mar 16, 2011, at 10:14 AM, Jason E. Aten wrote: > Dear Steve and lldb-dev, > > (starting a new thread to give a better, more appropriate, thread title) > > 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? > > 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. > > Thanks everyone! > > cheers, > Jason > > > details: > > ### On darwin, lldb starts a debugserver child process, and debugserver in > turn starts a child process to contain the debug target a.out. > > UID PID PPID > bash > | > V > 2086 42103 22537 0 0:00.07 ttyp0 0:00.16 ../lldb a.out > | > V > 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 > | > V > 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 > > > ### On linux, at the moment, what I see in contrast is that lldb is the > direct parent of the debug target (a.out here). > > jaten 4532 0.0 0.3 25752 8160 pts/3 Ss 03:59 0:01 > | \_ /bin/bash --noediting -i > jaten 22645 0.6 0.8 148260 18256 pts/3 Sl+ 11:57 0:00 > | | \_ ./lldb test-lldb/a.out > 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 > > > On Wed, Mar 16, 2011 at 9:40 AM, Jason E. Aten <[email protected]> wrote: > On Mon, Mar 14, 2011 at 11:11 PM, Stephen Wilson <[email protected]> wrote: > Well, in a nutshell you would need to implement something similar to > what ProcessLinux::DoLaunch does, but in this case you want things to > boil down to a ptrace(ATTACH) instead of a fork() + ptrace(TRACEME). > The basic sketch would be: > - Define a new ProcessMonitor ctor that takes a pid as argument. > - Define ProcessMonitor::Attach which does the actual ptrace magic. > - Write a another StartOperationThread method that takes a (new) > AttachArgs struct as argument (could just contain the pid for now) > and sets up the monitoring business in essentially the same way as > the current launch-based code does. Probably rename > OperationThread to LaunchOpThread or similar and write your own > AttachOpThread analog. > It would certainly be nice to have that implemented. I do not see > anything that would cause any complications off hand, and it should > remain fairly isolated from all the other work that needs to happen wrt > linux support. > > > 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. > > 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. > > 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. > > 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. > > 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! :-) > > Thanks, > Jason > > 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! > > > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
