<div dir="ltr">What would it take to make it so that local and remote process plugins use the same exact interface?  I mean in theory they're doing the same thing, just on a different machine.  If they shared an identical interface then you could hook the lldb-server up to it and it would work either locally or remotely.<div><br></div><div>What was the original motivation for having the api design of remote and local process plugins diverge?</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 28, 2016 at 12:56 PM Adrian McCarthy via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">In the near-term, I'm focused on postmortem debugging, so this wouldn't be a priority for me for a while.<br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Mon, Nov 28, 2016 at 12:43 PM, Greg Clayton <span dir="ltr" class="gmail_msg"><<a href="mailto:gclayton@apple.com" class="gmail_msg" target="_blank">gclayton@apple.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" 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 class="gmail_msg">
<br class="gmail_msg">
Greg<br class="gmail_msg">
<div class="gmail_msg"><div class="m_-7270101719721686963h5 gmail_msg"><br class="gmail_msg">
> On Nov 18, 2016, at 4:00 PM, Adrian McCarthy via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="gmail_msg" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> If you're not working in LLDB's Windows process plugin, you probably don't care about this message.<br class="gmail_msg">
><br class="gmail_msg">
> 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 class="gmail_msg">
><br class="gmail_msg">
> Details:<br class="gmail_msg">
><br class="gmail_msg">
> 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 class="gmail_msg">
><br class="gmail_msg">
> My plan is to do this in three NFC patches:<br class="gmail_msg">
><br class="gmail_msg">
> 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 class="gmail_msg">
><br class="gmail_msg">
> Patch 2.  Rename the -Live classes to shorter, more tractable names.<br class="gmail_msg">
><br class="gmail_msg">
> Patch 3.  Move the code up from the Live subdirectory so that it once again lives in Plugins/Process/Windows.<br class="gmail_msg">
><br class="gmail_msg">
> 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 class="gmail_msg">
><br class="gmail_msg">
> If you have any concerns about this plan, please let me know.<br class="gmail_msg">
><br class="gmail_msg">
> Adrian.<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
</div></div>> _______________________________________________<br class="gmail_msg">
> lldb-dev mailing list<br class="gmail_msg">
> <a href="mailto:lldb-dev@lists.llvm.org" class="gmail_msg" target="_blank">lldb-dev@lists.llvm.org</a><br class="gmail_msg">
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div><br class="gmail_msg"></div>
_______________________________________________<br class="gmail_msg">
lldb-dev mailing list<br class="gmail_msg">
<a href="mailto:lldb-dev@lists.llvm.org" class="gmail_msg" target="_blank">lldb-dev@lists.llvm.org</a><br class="gmail_msg">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br class="gmail_msg">
</blockquote></div>