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.
What was the original motivation for having the api design of remote and local process plugins diverge? On Mon, Nov 28, 2016 at 12:56 PM Adrian McCarthy via lldb-dev < lldb-dev@lists.llvm.org> wrote: > 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. > > In the near-term, I'm focused on postmortem debugging, so this wouldn't be > a priority for me for a while. > > 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. > > On Mon, Nov 28, 2016 at 12:43 PM, Greg Clayton <gclay...@apple.com> wrote: > > 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 >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
