[lldb-dev] Refactoring in LLDB Windows Plugin

[Adrian McCarthy via lldb-dev]

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 <gclayton at 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 at 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 at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20161128/ae0b10c8/attachment.html>