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