[lldb-dev] Process monitoring Host/Plugin interactions

[Zachary Turner]

So this email originally went through while I was still trying to come up
with a working solution.  So before I had arrived at the solution I came up
with in the patches I uploaded.

Anyway, some rambling ahead.

Ultimately I ended up not going through Host::LaunchProcess, so perhaps
most of the questions I asked are moot now.  In any case, the biggest
problem I had when trying to make ProcessWindows::DoLaunch use
Host::LaunchProcess is that the interface wasn't really flexible enough.
It seems that based on the distinction you describe between a process
status monitor and a debug monitor, Windows doesn't ever need to "monitor"
a process for anything.  At least not when debugging.

Passing it through as a flag like eLaunchFlagDontMonitor as you suggested
probably would work, but it seems like at that point we're sinking platform
specific flags into a generic interface.  If eLaunchFlagDontMonitor is set
if and only if we're launching a process for debugging on Windows, then
imagine if it were called eLaunchFlagWindowsProcess instead.

Part of me thinks that launching processes is just complicated, and maybe
we shouldn't try to mash it into one generic function (e.g.
Host::LaunchProcess).  That was the driving idea behind the ProcessLauncher
abstraction.  It allows launching strategies that are plugin specific, or
platform specific, to be implemented in plugin-specific or
platform-specific ways, or even in multiple different ways.

Of course at some level generic code needs to be able to have one function
that just says "hey, launch this process", but that function could simply
look at the flags in the ProcessLaunchInfo and create the correct type of
ProcessLauncher based on the flags that are specified.

A concrete example of how this is useful is because right now, it's unclear
what would happen in ProcessWindows if someone passed a monitor callback /
baton pair, because I just ignore it.  Really that just means that the idea
of the monitor callback and baton isn't actually generic enough, and maybe
would be better somewhere else.  But if you search through the code,
there's only a few very well-defined places where it's actually set.  The
most obvious example is running a shell command.  So here, you would just
have ShellProcessLauncher that does something different than
RegularProcessLauncher, or whatever.  You could remove the callback and
baton from ProcessLaunchInfo entirely.

Anyway, these are all just high level ideas.  FWIW, one of the reasons I'm
going out of my way and make great effort to create these abstractions in a
way that they're as reusable and generic as possible, is because it would
be great if everything I'm doing now just fits into llgs in the future
without a tremendous porting effort.  Not having posix compatibility in
Windows breaks alot of the assumptions that LLDB originally made, so
hopefully incrementally tackling these assumptions over time provides some
benefit in the long run.

On Fri Oct 31 2014 at 11:31:48 AM Greg Clayton <gclayton at apple.com> wrote:

>
> > On Oct 27, 2014, at 4:16 PM, Zachary Turner <zturner at google.com> wrote:
> >
> > 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.
>
> We could pass the launch flags (which would contain eLaunchFlagDebug and
> could be used to "do the right thing") into the process monitor. Would that
> solve the issue?
>
> >
> > 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 do think there is usually a difference between the "process status
> monitor" and the "I have a special connection to a process because I am
> debugging it and need all exceptions and other very low level stuff.". So I
> am not sure it is a great idea to try and merge the two.
>
> >
> > 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.
>
> Think about the difference between monitoring the process and debugging a
> process. They are quite different for MacOSX. I believe they are as well on
> linux (waitpid() is not used as the main way to figure out if a process has
> stopped due to a breakpoint for example, and windows seems to be quite
> different).
>
> A simpler approach might be to allow clients to specify if a process
> should be monitored when launching with a new eLaunchFlagDontMonitor. Only
> windows would set this from its ProcessWindows::DoLaunch() and then it can
> run the more complex thread that tracks a process for debugging. On Linux
> and MacOSX, it is quite ok to monitor a process with waitpid(), and also be
> debugging it with ptrace() or being attached to a task port with MacOSX.
>
> Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141031/dc32571e/attachment.html>