> On Oct 24, 2014, at 11:53 AM, Zachary Turner <ztur...@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



_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to