[Lldb-commits] [PATCH] D63165: Initial support for native debugging of x86/x64 Windows processes

Thu Jul 18 08:18:38 PDT 2019

amccarth requested changes to this revision.
amccarth added a comment.
This revision now requires changes to proceed.

In D63165#1541944 <https://reviews.llvm.org/D63165#1541944>, @clayborg wrote:

> In D63165#1540606 <https://reviews.llvm.org/D63165#1540606>, @Hui wrote:
>
> > > In D63165#1539118 <https://reviews.llvm.org/D63165#1539118>, @amccarth wrote:
> > > 
> > >> Sorry for the stupid question, but ...
> > >>
> > >> What exactly is meant here by "Native"?  How is a NativeProcessWindows different from ProcessWindows?
> > > 
> > > 
> > > The Native*** classes are meant to be used from lldb-server. They look somewhat similar to their non-native counterpart because they still do debugging, but they're a lot dumber, because they only deal with basic process control, and none of the fancy symbolic stuff that you'd need debug info for.
> >
> > They differ in APIs but most of them have common implementations. The APIs from native process classes are more easy to apply process/thread control.
> >  Hope the native and non-native ones can be merged. The similar thing to the RegisterContext and NativeRegisterContext classes.
> >
> > The other thing is that using "native" classes can avoid linking a lot of unnecessary lldb libs (LLDB plugins or whatever comes with the plugins) to lldb-server.
> >  The nativeprocesswindows could just be a pass-through to processwindows plugin, but the usage is a sort of strange since the
> >  lldb-server needs to initialize the plugin, create a target, and create a instance just like what lldb does. This means literally
> >  there will be two lldb debuggers, one on host and the other one on remote. It is  doable, but not that applicable.
>
>
> So the idea is ProcessWindows will be deleted once lldb-server supports windows debugging. A bit of history here: when we first started we started making ProcessXXXX for each platform (mac, linux, windows). Then we thought about remote debugging and decided to have everyone just make a lldb-server for their platform and even when we are locally debugging, we launch a lldb-server. This is how linux, macOS, the BSDs and other targets do it. Why? Because if you do it the other way you have more code to support: one native plug-in and one remote plug-in. This means the remote debugging usually has more issues since it is the less tested debugging scenario. It also means that if you had a native process implementation only, like ProcessWindows is currently, you can't remotely debug to a windows machine.
>
> So yes there is duplicated code for now, but ProcessWindows.cpp and ThreadWindows.cpp should go away in the near future once lldb-server takes over so the temporary code duplication is just to keep things working until lldb-server takes over.

Thanks for all the clarification.  "Native" is an overloaded term in LLDB.

I'm trying to think through the implications of this always-use-an-lldb-server approach on cross-platform postmortem debugging.  I'll have to do some studying, but I guess this patch doesn't change anything in that regard.

================
Comment at: lldb/source/Plugins/Process/Windows/Common/NativeProcessWindows.cpp:95
+
+    // Resume the debug loop.
+    ExceptionRecordSP active_exception =
----------------
This code appears to be based on `ProcessWindows::DoResume`, which has a pending patch to fix a race condition by moving the checking of the exception record to later in the function.  I assume this will need the same fix.  See https://reviews.llvm.org/D62183 for details.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63165/new/

https://reviews.llvm.org/D63165