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

Thu Jun 13 08:59:15 PDT 2019

clayborg added a comment.

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.

Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D63165