wallace added inline comments.
================
Comment at: lldb/source/API/SBProcess.cpp:772
- return (event.GetBroadcasterClass() == SBProcess::GetBroadcasterClass()) &&
- !EventIsStructuredDataEvent(event);
+ return Process::ProcessEventData::GetEventDataFromEvent(event.get()) !=
+ nullptr;
----------------
+1
================
Comment at: lldb/tools/lldb-vscode/lldb-vscode.cpp:1976
+ if (state != lldb::eStateConnected) {
+ process.Kill();
+ }
----------------
Kill actually detaches if lldb originally attached to the debuggee. The actual
implementation says
```
/// Kills the process and shuts down all threads that were spawned to track
/// and monitor the process.
///
/// This function is not meant to be overridden by Process subclasses.
///
/// \param[in] force_kill
/// Whether lldb should force a kill (instead of a detach) from
/// the inferior process. Normally if lldb launched a binary and
/// Destory is called, lldb kills it. If lldb attached to a
/// running process and Destory is called, lldb detaches. If
/// this behavior needs to be over-ridden, this is the bool that
/// can be used.
///
/// \return
/// Returns an error object.
Status Destroy(bool force_kill);
```
You could have the restart command reattach to the process instead of failing
if the user originally attached.
What do you think of this?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D147831/new/
https://reviews.llvm.org/D147831
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
