[lldb-dev] Process spawning and shutdown

[Todd Fiala]

> 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 <zturner at 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 <tfiala at 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 <zturner at 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 at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>>
>>
>> --
>> Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
>>
>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140916/00c87e9b/attachment.html>