One thing that we have talked about is to move the ProcessWindows stuff into 
lldb-server (it has a NativeProcess and NativeThread class you would need to 
subclass instead of making ProcessWindows and ThreadWindows classes) instead of 
making a native plug-in that is only useful on the current system. Then remote 
windows debugging would be possible. It would end up using thee 
ProcessGDBRemote.cpp process plug-in then. Then the ProcessWindows plugin 
directory would not be needed. Any thoughts on this?

Greg

> On Nov 18, 2016, at 4:00 PM, Adrian McCarthy via lldb-dev 
> <lldb-dev@lists.llvm.org> wrote:
> 
> If you're not working in LLDB's Windows process plugin, you probably don't 
> care about this message.
> 
> FYI:  I'm doing some refactoring (actually unfactoring) in the Windows 
> process plugin.  It'll take a series patches over a few days next week.  If 
> you're planning on working in this area, please let me know so we can 
> coordinate.
> 
> Details:
> 
> Last year, I factored the classes like ProcessWindows into pairs of classes 
> with names like ProcessWindows and ProcessWindowsLive so that I could 
> introduce classes like ProcessWindowsMiniDump that shared common code.  Now 
> that the Windows-specific minidump plugin has been superseded by the 
> cross-platform minidump plugin, this factoring is no longer necessary.  Since 
> the factoring creates extra layers that make the code harder to understand 
> and maintain, I'd like to undo the split.
> 
> My plan is to do this in three NFC patches:
> 
> Patch 1.  Roll the functionality from the common classes into the -Live 
> classes.  This will eliminate everything under Plugins/Process/Windows/Common 
> and leave the functional code in Process/Plugins/Windows/Live.
> 
> Patch 2.  Rename the -Live classes to shorter, more tractable names.
> 
> Patch 3.  Move the code up from the Live subdirectory so that it once again 
> lives in Plugins/Process/Windows.
> 
> Patches 2 and 3 could be done in a single step, but I think the history will 
> be easier to follow if I keep them separate.
> 
> If you have any concerns about this plan, please let me know.
> 
> Adrian.
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to