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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
