> For now, the abstraction I'm creating deals only with local processes.
For MacOSX, the local process uses debugserver for debugging (i.e. it is always remote w/r/t process startup --- lldb will launch and debugserver will attach). Linux is moving this way as well once we (1) get llgs passing the local test suite with llgs in place of ProcessLinux/ProcessMonitor, and (2) get llgs supporting the existing set of ProcessLinux/ProcessMonitor cpu architectures. It will be on a PlatformLinux switch that defaults to current TOT behavior until then. (See http://github.com/tfiala/lldb in the dev-llgs-local-launch branch for current state). Not sure that affects anything but wanted to be clear on it. On Tue, Sep 16, 2014 at 12:26 PM, Zachary Turner <ztur...@google.com> wrote: > Yea, I saw that as well. For now, the abstraction I'm creating deals only > with local processes. However, it has an interface that would in theory > allow a RemoteProcess to derive from it, so that local and remote processes > could be managed transparently. > > On Tue, Sep 16, 2014 at 12:07 PM, Todd Fiala <tfi...@google.com> wrote: > >> Don't forget we also have launching via Platform classes, which can end >> up kicking off a gdb-remote request to a lldb-platform or gdb-remote stub >> (llgs/debugserver). >> >> Also, ProcessGDBRemote is capable of kicking those off if it's using >> gdb-remote locally. >> >> So, if nothing else, there's the concept of a "launch via another >> mechanism." >> >> On Tue, Sep 16, 2014 at 11:55 AM, Zachary Turner <ztur...@google.com> >> wrote: >> >>> The last major piece of the Host layer I'd like to address is process >>> launching and cleanup. From looking over the code it seems we have the >>> following different ways to launch a process: >>> >>> MacOSX: >>> * Applescript >>> * XPC >>> * posix_spawn >>> >>> Other posix variants: >>> * posix_spawn >>> >>> Windows: >>> * Native windows launcher >>> >>> >>> Among these, there are a couple of different ways to reap processes on >>> exit and/or "join" on them. These are: >>> >>> MacOSX: >>> * Applescript [ No process reaping or monitoring occurs. ] >>> * XPC [ Uses MacOSX-specific dispatch library for >>> monitoring ] >>> * posix_spawn [ Uses MacOSX-specific dispatch library for >>> monitoring ] >>> >>> Other posix variants: >>> * posix_spawn [ Launches a background thread to monitor for >>> process exit, join on the thread to join on the process ] >>> >>> Windows: >>> * Native windows launcher [ WaitForSingleObject ] >>> >>> A few questions: >>> >>> 1) Is Join() on a process a useful operation that people would be >>> interested in seeing implemented for all platforms? >>> >>> 2) On Linux at least, if you don't waitpid() on a process you'll end up >>> with zombies. It seems this is true on MacOSX as well, because I see >>> waitpid() in StartMonitoringChildProcess. Is this not true for the >>> Applescript launcher? Why doesn't the Applescript launching code path call >>> StartMonitoringChildProcess() anywhere? >>> >>> 3) Speaking of the Applescript launcher, what is it and what is it used >>> for? >>> >>> >>> I'll probably have more questions as I wrap my head around this a little >>> more. Thanks >>> >>> _______________________________________________ >>> lldb-dev mailing list >>> lldb-dev@cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >>> >> >> >> -- >> Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180 >> > > -- Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
