[lldb-dev] Process monitoring Host/Plugin interactions

[Zachary Turner]

What is the monitor_signals variable supposed to represent?  Windows
doesn't have signals, so maybe I can just ignore this variable.  Looking
through the code, it seems like even MacOSX doesn't use this, and just
always sets it to false, and the only place this is ever set to true is in
Linux and FreeBSD.  Maybe Todd knows?  (I don't have his email new address,
but maybe you can +cc him on this email if you don't know the answer).

I kind of feel like the code would be clearer if ProcessMonitor were an
abstract interface in Host, then DefaultWindowsProcessMonitor could do what
it needs to do, DefaultPosixProcessMonitor could do what it needs to do,
ProcessLaunchInfo could just have a pointer to a ProcessMonitor instead of
both a callback and a baton,  it would be easier to chain callbacks like
this because the class could store a list of callbacks instead of just 1,
and this monitor_signals flag could be a member variable of
LinuxProcessMonitor so that other platforms wouldn't have to worry about
dubiously ignoring it.  Anyway, I've had enough refactoring for a while,
just thinking out loud.

On Fri, Oct 24, 2014 at 2:45 PM, Greg Clayton <gclayton at apple.com> wrote:

>
> > On Oct 24, 2014, at 1:58 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > So right now I have ProcessWindows::DoLaunch() set up to just call
> Host::LaunchProcess and pass the ProcessLaunchInfo along.  This uses the
> default default monitoring algorithm that's built into the host layer,
> which basically just waits for the process to exist and nothing else.  This
> doesn't work in the case of a debugged process, because there's no initial
> stop so Process::Launch (in Target/Process.cpp) doesn't ever get the
> notification that the process launched successfully.
> >
> > Is the solution then to just keep the default monitoring algorithm in
> Host as is, but in ProcessWindows::DoLaunch(), specify a different callback
> before passing it through to Host::LaunchProcess?
>
> Yes, this is what you must do since you will want to call
> Process::SetExitStatus(...).
>
> >  This is roughly what ProcessLinux does, but I wonder what happens if
> ProcessWindows::DoLaunch() has received a ProcessLaunchInfo that has a
> user-specified monitoring callback.
>
> You would need to chain it an call theirs from yours.
>
> >
> > On Fri, Oct 24, 2014 at 1:45 PM, Greg Clayton <gclayton at apple.com>
> wrote:
> >
> > > On Oct 24, 2014, at 11:53 AM, Zachary Turner <zturner at google.com>
> wrote:
> > >
> > > I'm going to tackle implementing process monitoring for Windows next,
> and I've started going over how this works for other platforms.
> > >
> > > There's a bit of a confusing interaction between Host, Target, and the
> individual plugins, and I'm wondering if it might make more sense to put
> the monitoring code somewhere other than Host.
> > >
> > > From what I can tell, launching a process for debugging goes something
> like this:
> > >
> > > 1) Call ProcessPlugin::DoLaunch
> > > 2) some system calls to actually launch the process
> > > 3) Call Host::StartMonitoringChildProcess with callback set to
> somewhere in your plugin.
> > > 4) The monitoring thread (in Host) periodically calls back into
> ProcessPlugin
> > >
> > > For starters, this seems to be broken in the case where the
> ProcessLaunchInfo has pre-set an m_monitor_callback because the plugins end
> up just ignoring this and using their own callback.
> > >
> > > Ultimately, how a process is monitored is going to depend on the
> plugin, so shouldn't StartMonitoringChildProcess also be part of the
> plugin?  In what situation would you ever want to monitor a child process
> that is not under the control of some process plugin?
> >
> > Any process you launch that you aren't going to debug. Like launching a
> shell command or just say running "debugserver" in order for _it_ to be
> able to debug your application along with ProcessGDBRemote.
> ProcessGDBRemote is very interested if the "debugserver" process dies
> because it crashes, so it can kill the debug session and say "debugserver
> exited with status 12". Also when running a shell command you need to be
> able to run the shell command and find out when the shell command exits.
> >
> > So the monitoring of the process definitely will stay in the host layer.
> The host layer can and should be used to launch any process (though some
> plug-ins might not be respecting that and they might be doing it
> themselves. The idea is we write the process launching code once in the
> host layer, then lldb-gdbserver, lldb-platform, and lldb can all use that
> one copy of the code to correctly launch processes and monitor (for
> signals) and reap them (get exit status and know that any stdout/stderr can
> now be forwarded onto whomever needs it.
> >
> > Greg
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141024/4834483b/attachment.html>