[lldb-dev] Host::LaunchProcess vs. ProcessPlugin::DoLaunch

Greg Clayton gclayton at apple.com
Tue Aug 12 15:55:45 PDT 2014


> On Aug 11, 2014, at 10:47 AM, Zachary Turner <zturner at google.com> wrote:
> 
> So one thing I'm still unclear about, is exactly when I will receive a launch request through the Process plugin versus when I will receive the request directly through the Host without first going through the Process plugin.

This is mostly cruft from when we first brought up LLDB without having the Platform or the Host layer fully implemented.

The preferred option is to have your PlatformWindows do the launching by using the Host::LaunchProcess():

    static Error
    Host::LaunchProcess (ProcessLaunchInfo &launch_info);

The ProcessLaunchInfo contains a flag to indicate when the process wants to be debugged:

    if (launch_info.GetFlags().Test (eLaunchFlagDebug))
    {
        // Do something to make the process stop at entry point...
    }

So your PlatformWindows should implement LaunchProcess:


Error
PlatformWindows::LaunchProcess (ProcessLaunchInfo &launch_info)
{
    if (IsHost())
    {
        error = Platform::LaunchProcess (launch_info);
    }
}


Platform::LaunchProcess() already uses the Host::LaunchProcess(). Other code will then use the Process::Attach() to attach to that process by process ID.

The best part about implementing the Host::LaunchProcess() is you implement your launching code once, and it gets used by the platforms, by the lldb-platform (to allow remote debugging to a windows machine via lldb-gdbserver). You should then be implementing a ProcessNative subclass and using Todd Fiala's lldb-gdbserver code to get debugging working. This will get you remote debugging for free and you won't need a ProcessWindows subclass at all, you will just use the ProcessGDBRemote.

Greg Clayton





More information about the lldb-dev mailing list