[lldb-dev] Process monitoring Host/Plugin interactions

[Zachary Turner]

I keep coming back to this interface solution.  The issue I'm having is
that I need completely different monitoring algorithms for when the process
is launched as a debug target versus something like a shell command or
utility process where I only want to know when it exits.  In both cases it
will spawn a thread and run some code in the thread, but the code that runs
in the thread will be different.

On the other hand, Process launching and monitoring should be initiated by
Host, since it is common functionality, and as you said previously process
plugins should be using Host::LaunchProcess but may not be respecting that.

So the issue is: I need my process plugin to be able call
Host::LaunchProcess in such a way that Host::LaunchProcess knows to use a
different monitoring algorithm.

But then things get tricky.  The algorithm it needs to use in the case of a
debug target does not really belong in Host, because it will allow me to
detect events like dll loads / unloads, thread creation, child process
spawning, exceptions, and other things.  So this code belongs in the
process plugin.  The cleanest way I can come up with to really handle this
is to let Host implement this interface in such a way that it only monitors
for exit status, and let my plugin implement it in such a way that it
monitors for all the other stuff as well.

If you're opposed to this, I can "make it work" it's going to involve
implementing ProcessWindows::DoLaunch without the help of
Host::LaunchProcess(), which is what I was trying to avoid.

I think the high level notion of a process status monitor (note this what
I'm calling a process status monitor is *much *more narrowly defined than
what is encompassed by the ProcessMonitor class in Linux and FreeBSD)
applies to all platform, regardless of whether we're doing local debugging,
lldb-gdbserver, or even no debugging at all (e.g. running a shell command),
so I think it's generally useful.

I can do this in such a way that (for now anyway) only Windows actually
makes use of this interface and other platforms' logic remains untouched,
with the idea of using it in the future (after llgs is more cemented, for
example).

What are your thoughts?  If you need to see some code to make things
concrete, I can upload a patch.

I'm still open to other solutions, but ultimately goal is just to find the
right abstraction to get the highest amount of code reuse so that all
platforms can benefit from each others' improvements without having to
write a bunch of platform specific code themselves.


On Mon Oct 27 2014 at 11:39:51 AM Greg Clayton <gclayton at apple.com> wrote:

>
> > On Oct 27, 2014, at 11:17 AM, Zachary Turner <zturner at google.com> wrote:
> >
> >
> >
> > On Mon Oct 27 2014 at 10:52:53 AM Greg Clayton <gclayton at apple.com>
> wrote:
> >
> > > On Oct 24, 2014, at 3:38 PM, Zachary Turner <zturner at google.com>
> wrote:
> > >
> > > What is the monitor_signals variable supposed to represent?  Windows
> doesn't have signals, so maybe I can just ignore this variable.
> >
> > You can ignore this for windows. The typical way to monitor a child
> process is to call waitpid() which will tell you about signals and exit
> status. Is there no way to communicate anything between a process via the
> handle other than the process exiting?
> > The handle is the only interface to the process.  So basically if it's
> an operation that can be performed, or a query that can be answered, it
> happens through a handle.  What are some use cases for setting
> monitor_signals to true?  For example, in Windows (at least when a process
> is being debugged), we can detect things like thread creation, dll (e.g.
> shared object) load and unload, exceptions (divide by zero, segfault,
> etc).  Would this kind of thing fall under the category of what a user
> might expect to monitor when monitor_signals is true?
>
> No, this would be something along the lines let me launch a subprocess and
> and the subprocess would send a SIGUSR1 or SIGUSR2 up to the parent process
> when it wants some more data. The parent process would wait for the signals
> and then send more data to the child process. Or you have a parent process
> that launches the "compile 100 source files" subprocess and wait for 100
> SIGCHLD (child process has exited) signals to be sent back to the parent
> process. Again, this is unix behavior and we don't use it for debugging,
> but if we are abstracting the OS through a host layer we better support it,
> or we might end up with someone just calling posix_spawn directly and using
> waitpid() and monitoring the process with their own thread if we don't.
> Then things don't run on windows and our host abstraction falls down.
>
> >
> > If there's a way to map this monitor_signals flag to something that
> makes sense on Windows, then I could try to find the common ground and
> change the name of the variable accordingly.  Otherwise I can just ignore
> it.
>
> Whatever we want to support, we can add/change the callback if needed. So
> I would look into IPC on windows and see if any the process handle gets
> used for any of that, and see if we can easily abstract that into something.
> >
> >
> >
> > >  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).
> >
> > We are just exposing a feature that people launching subprocesses really
> might need. People can use signals to communicate between processes, so our
> host layer needs to include this. Another approach would be to return a
> launch error if anyone requests monitoring signals on windows.
> >
> > >
> > > I kind of feel like the code would be clearer if ProcessMonitor were
> an abstract interface in Host
> >
> > We don't use ProcessMonitor on MacOSX.
> >
> > > 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.
> >
> > I  would prefer to avoid this and just have you ignore or return an
> error if this flag is set. Reasons being, ProcessMonitor is only used by
> linux and doesn't really need to be in LLDB anymore. We really should be
> switching over to using lldb-gdbserver (it would be great if windows did
> this) so we get remote debugging for all platforms.
> >
> >
> > I imagine that switching switching to lldb-gdbserver on Windows will
> happen in the medium to long term, but local debugging and core dump
> debugging is 90% of what we need, and also significantly less effort.  Once
> there's more people than just me working on it though things should happen
> more quickly.
> >
> > Regarding MacOSX and process monitor it does seem to monitor processes
> (in the sense that it calls waitpid to get status updates), it just doesn't
> use a class called ProcessMonitor in the plugin the same way the Linux
> stuff does.  All the platforms have need of the same high level
> functionality, so it seems like it would be good to unify all this and make
> the interfaces consistent, as it opens up more possibilities for code
> reuse.  Even if it's transitioning to lldb-gdbserver, it just means
> lldb-gdbserver will need to monitor processes.
> >
> > In any case, I do plan to just ignore the monitor_signals flag for now,
> and maybe log a warning or something
>
> Sounds good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141027/4a7db8c9/attachment.html>