> On Oct 27, 2014, at 4:16 PM, Zachary Turner <ztur...@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 _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
