> On Oct 24, 2014, at 1:58 PM, Zachary Turner <ztur...@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 <gclay...@apple.com> wrote: > > > 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
