[lldb-dev] Process monitoring Host/Plugin interactions

[Zachary Turner]

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?

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.



> >  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141027/85276357/attachment.html>