The theory here is that the stuff would be for the host layer and would be used
in NativeProcess and NativeThread, which do belong in the host layer. I am fine
with the move if it is needed, but the theory is these are base classes for
code that should be in the host layer. That said, the base
As I understood it originally, the NativeProcess stuff would end up replacing
the guts of the ProcessLinux, etc, but in a way that would easily allow you to
slot them into llgs as well. That’s why I thought of them as some kind
ur-process plugin.
Jim
http://reviews.llvm.org/D6123
On Nov 4, 2014, at 2:31 PM, Zachary Turner ztur...@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,
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 clayb...@gmail.com wrote:
On Nov 4, 2014, at 2:31 PM, Zachary Turner ztur...@google.com wrote:
Looking at this more
On Nov 4, 2014, at 2:47 PM, Zachary Turner ztur...@google.com wrote:
As an aside, is there a roadmap for getting all supported Darwin platforms on
llgs for both local and remote debugging?
No immediate plans as this is just busy work. I believe someone externally has
an native MacOSX
Sure, that seems fine to me.
Jim
On Nov 4, 2014, at 3:22 PM, Zachary Turner ztur...@google.com wrote:
Based on Jim's comments, it sounds like this code might be moving around in
the future anyway, once the Native stuff goes away and a better code
organization is finalized. Based on
Sure, that seems fine to me.
Jim
http://reviews.llvm.org/D6123
___
lldb-commits mailing list
lldb-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
