[Lldb-commits] [PATCH] Move NativeProcessProtocol and friends from Host/ to Target/

[Greg Clayton]

> On Nov 4, 2014, at 2:31 PM, Zachary Turner <zturner at google.com> 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