[lldb-dev] MacOSX attaching to process

[Jim Ingham]

On Jul 28, 2012, at 11:08 PM, Benjamin Kemper <kemperbenny at gmail.com> wrote:

> 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?

XPC handles the privilege escalation if you want to attach to a root process from a user account.  Facilitating a design where privileged operations are done in small special purpose tools is actually one of the principle roles of XPC on OX X.

> 
> 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?

Because ptrace doesn't support reading & writing memory or registers on X.  Those can only be done with the mach calls.  You might want to ask the follow up question why those ptrace functions aren't supported on Mac OS X, but you'd have to find somebody who was at NeXT 15 or 20 years ago to get the answer to that one.

Jim


> 
> 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
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Jim Ingham
Apple Developer Tools