> On Aug 11, 2014, at 10:47 AM, Zachary Turner <[email protected]> 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
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
