<div dir="ltr">I have no objection to moving in that direction (enabling remote debugging).  Zach just pointed out that we'd first have to port lldb-server to Windows.  Offhand, I don't know how much of an effort that would be.<div><br></div><div>In the near-term, I'm focused on postmortem debugging, so this wouldn't be a priority for me for a while.<br></div><div><div><br></div><div>The "unfactoring" I mentioned in this email is essentially done, though I'm planning to move some files to eliminate an unnecessary subdirectory from the source paths.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 28, 2016 at 12:43 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<br>
<br>
Greg<br>
<div><div class="h5"><br>
> On Nov 18, 2016, at 4:00 PM, Adrian McCarthy via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> If you're not working in LLDB's Windows process plugin, you probably don't care about this message.<br>
><br>
> 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.<br>
><br>
> Details:<br>
><br>
> 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.<br>
><br>
> My plan is to do this in three NFC patches:<br>
><br>
> 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.<br>
><br>
> Patch 2.  Rename the -Live classes to shorter, more tractable names.<br>
><br>
> Patch 3.  Move the code up from the Live subdirectory so that it once again lives in Plugins/Process/Windows.<br>
><br>
> 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.<br>
><br>
> If you have any concerns about this plan, please let me know.<br>
><br>
> Adrian.<br>
><br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div><br></div>