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

[Zachary Turner]

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 <clayborg at gmail.com> wrote:

>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20141104/10aacd17/attachment.html>