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
