As an aside, is there a roadmap for getting all supported Darwin platforms on llgs for both local and remote debugging?
On Tue Nov 04 2014 at 2:43:55 PM Greg Clayton <[email protected]> wrote: > > > On Nov 4, 2014, at 2:31 PM, Zachary Turner <[email protected]> wrote: > > > > Looking at this more closely, it seems to me like the process plugins > contain two disjoint codepaths. An llgs codepath (NativeProcessLinux, > NativeProcessProtocol, etc) and a local debugging codepath (ProcessLinux, > ProcessMonitor, etc). > > > > This whole patch arose out of an effort to get local debugging working > on Windows, because it looked like I needed to go through these > NativeProcessProtocol and whatever. But now it looks like this is not the > case. > > There are two ways to do debugging: > 1 - implement your own ProcessWindows (which you are doing) > 2 - implement by subclassing NativeProcess and NativeThread so that > debugging can be implemented in llgs. > > We prefer #2 for new stuff so that we get remote debugging for free. Later > we can make a new process plug-in that uses NativeProcess and NativeThread, > but we haven't done that yet. The theory is one set of code should be able > to be used to debug locally and remotely and we hope people opt to do > remote debugging even locally like we do on MacOSX to ensure that remote > debugging always works well and is not one of those things that barely gets > any testing. > > > It's not entirely clear why more of the code from ProcessLinux and the > local debugging codepath wasn't re-used for the llgs side, > > I believe Todd Fiala communicated this to you, but to re-iterate: > - ProcessMonitor/ProcessLinux will soon be going away in favor of the > NativeProcess/NativeThread subclasses that are in llgs. Linux will soon > switch over llgs for both native and remote debugging as soon as llgs is as > good as the ProcessLinux. The Google Android LLDB guys are working hard to > get the last ~30 tests passing with llgs and then the cutover will happen > shortly thereafter. Vince Harron can give you all the details. > > > > but either way it looks like maybe I don't need to go down this route, > and I can just have my debug driver thread communicate directly with > ProcessWindows. > > You can, but again llgs is the preferred method going forward which means > implementing NativeProcess and NativeThread. > > > I'm happy to still commit this change (or make improvements as > requested) if there's a better way to organize the code, but I'm also okay > abandoning it since it seems it isn't necessary to get debugging working on > this end. > > > > http://reviews.llvm.org/D6123 > > Work things out with Jim and we can get your stuff checked in. > > Greg
_______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
