> 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.woodw...@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-boun...@cs.uiuc.edu [mailto:lldb-dev-boun...@cs.uiuc.edu]
> *On Behalf Of *Zachary Turner
> *Sent:* Tuesday, September 16, 2014 3:26 PM
> *To:* Todd Fiala
> *Cc:* lldb-dev@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 <tfi...@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 <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
>
>
>
>
>
--
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
