[lldb-dev] Process spawning and shutdown

[Todd Fiala]

> I’d like to be able to have “run” be able to launch a supplied
executable, then connect to it via gdb-remote (or another protocol).


That sounds a lot like running an lldb-platform for a platform, and having
the lldb-platform launch the stub.  That scenario sounds like it would map
well to the 'platform select remote-{something}', 'platform connect
connect://{remote-address}:{remote-port}' paradigm?

On Tue, Sep 16, 2014 at 1:59 PM, Ted Woodward <ted.woodward at codeaurora.org>
wrote:

> I’d like to add another use case. On Hexagon, we talk to a simulator using
> gdb-remote. We hacked gdb to have “run” launch and connect to the
> simulator, and “start” do a “run”, then break at main and continue. I’ve
> implemented this in our lldb solution using python.
>
>
>
> I’d like to be able to have “run” be able to launch a supplied executable,
> then connect to it via gdb-remote (or another protocol).
>
>
>
> *From:* lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu]
> *On Behalf Of *Zachary Turner
> *Sent:* Tuesday, September 16, 2014 3:26 PM
> *To:* Todd Fiala
> *Cc:* lldb-dev at cs.uiuc.edu
> *Subject:* Re: [lldb-dev] Process spawning and shutdown
>
>
>
> Sure, but debugserver still has to launch processes locally w/r/t itself,
> so this code would jsut be used there instead of in lldb.  Also, it's not
> clear what the timeline is and waiting would jsut be lost time, so even if
> some of what I do now has to be redone in the debugserver world, it's still
> better than being blocked now and not being able to do anything :)
>
>
>
> On Tue, Sep 16, 2014 at 1:12 PM, Todd Fiala <tfiala at google.com> wrote:
>
> > 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
>
>
>
>
>



-- 
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/20140917/544904c3/attachment.html>