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

[Greg Clayton]

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 <j.e.aten at gmail.com> wrote:
> On Mon, Mar 14, 2011 at 11:11 PM, Stephen Wilson <wilsons at start.ca> 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
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev