[lldb-dev] MacOSX attaching to process

[Benjamin Kemper]

Thanks for the great answers!

So for what exactly do you need XPC?
If you are using by default debugserver to handle the control of the
application, and I'm guessing you are communicating with over it TCP the
same as GDB, then XPC is planned for interprocess communication instead of
TCP?

I've seen that LLDB uses vm_write/read system calls to read and write
memory, is there a reason ptrace is not used for that?

Thanks again for the great answers,
Benjamin.

On Thu, Jul 26, 2012 at 8:32 PM, Jim Ingham <jingham at apple.com> wrote:

>
> On Jul 26, 2012, at 9:18 AM, Filipe Cabecinhas <filcab at gmail.com> wrote:
>
> > Hi Benjamin,
> >
> > On Thursday, July 26, 2012 at 11:54 AM, Benjamin Kemper wrote:
> >
> >> Hi,
> >>
> >> I've been trying to figure out how does the attaching to process works
> in OSX, and have some questions regarding it.
> >>
> >> From what I've noticed, the two available "Process" classes are:
> >> 1. ProcessGDBRemote
> >> 2. ProcessKDP (Which seems to be not supported)
> >>
> >> It looks like that ProcessPOSIX isn't included anywhere in OSX classes,
> so I'm guessing it is not used in OSX.
> >>
> > Nope, it isn't.
> > ProcessKDP is for debugging the Mac OS X kernel extensions, AFAICT.
>
> Well, not just kernel extensions, it is for general kernel debugging.
>
> > ProcessGDBRemote is what is used on Mac OS X for debugging right now.
> The lldb team wanted to be sure that remote debugging worked, so they
> focused on being able to do Mac-to-Mac and Mac-to-iPhone remote debugging.
> That way you can debug both ways: locally or remote.
>
> Right, we already had debugserver hanging around from the original iPhone
> tools which used gdb, so it made sense to use this.
>
> >
> >> So from what I understand, if a user wants to debug a program locally
> on the host it goes like this:
> >> 1. LLDB creates the debugee using posix_spawn with flag that tells it
> to wait until attached.
> >> 2. A debug server is launched through an XPC process (to get privileges
> to use PTrace?)
> >> 3. The debug server attaches to the process that was launched in (1).
> >>
> >> Is this scenario correct for "regular" debugging (not remote and
> attaching to an already running process)?
> >>
> >> Is the use of the debug server only because of the XPC limitiations and
> being able to use PTrace?
> >>
> >> Thanks in advance,
> >> Benjamin.
> >
> >
> > XPC isn't involved for most cases.
> > In ProcessGDBRemote::StartDebugserverProcess you can see how debugserver
> gets spawned using Host::LaunchProcess.
> > That function will only use XPC to launch a process if you asked it to
> launch with a kid of 0. Otherwise, it will use posix_spawn.
> > After debugserver gets launched, the Process plugin connects to it and
> sends and receives commands.
> >
> > The Linux and FreeBSD plugins don't do this (use debugserver). Actually,
> if it didn't change from the last time I saw it, debugserver isn't even
> portable and needs lots of changes to decouple it from Mac OS X.
>
> The platform specific bits of debugserver have creeped up into the generic
> code, though fixing that and adding a Linux/FreeBSD layer wouldn't be too
> hard.  But that wouldn't be the right place to put effort. The correct
> design would be for lldb to include native debugging plugins for all the
> platforms we support, and then debugserver should be built on top of them.
>  That way we wouldn't end up in the same situation as gdb & gdbserver where
> you have to maintain two separate implementations of the process control
> logic.  If somebody is interested in doing this work, we have thought about
> how we would approach it and would be glad to help out.  Having debugserver
> available is generally useful, so this would be a good project.  It's going
> to take a while for us to get around to it, however, since we would be
> replacing an already working debugserver and it is always hard to book time
> to do something that while undoubtedly formally more correct, makes no
> noticeable change to the users of your tool.
>
> Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20120729/8aac67b2/attachment.html>