[lldb-dev] MacOSX attaching to process
jingham at apple.com
Thu Jul 26 10:32:14 PDT 2012
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:
>> 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,
> 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.
More information about the lldb-dev