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

[Jason E. Aten]

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