[Lldb-commits] [PATCH] D100191: [lldb] [llgs] Support owning and detaching extra processes
Pavel Labath via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Wed Apr 14 11:36:10 PDT 2021
labath added inline comments.
================
Comment at: lldb/include/lldb/Host/common/NativeProcessProtocol.h:226
+ NewSubprocess(NativeProcessProtocol *parent_process,
+ std::unique_ptr<NativeProcessProtocol> &child_process) = 0;
};
----------------
That way, the delegate _must_ do something with the child process.
================
Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:3202-3209
if (!m_current_process ||
(m_current_process->GetID() == LLDB_INVALID_PROCESS_ID)) {
LLDB_LOGF(
log,
"GDBRemoteCommunicationServerLLGS::%s failed, no process available",
__FUNCTION__);
return SendErrorResponse(0x15);
----------------
I don't think this makes sense anymore....
================
Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:3237
+ __FUNCTION__, it->first, error.AsCString());
+ return SendErrorResponse(0x01);
+ }
----------------
It might be better to carry on detaching even if one process fails, and then return the errors in batch (?)
Something like:
```
Error err = Error::success();
for (p : processes) {
if (Error e = p.second.Detach().ToError())
err = joinErrors(std::move(err), std::move(e));
}
if (err)
SendErrorResonse(std::move(err));
```
================
Comment at: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:3249
+ if (!detached)
+ return SendErrorResponse(Status("PID %" PRIu64 " not traced", pid));
----------------
Open question: Should we return an error for a plain `D` packet, if we don't have _any_ processes around?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D100191/new/
https://reviews.llvm.org/D100191
More information about the lldb-commits
mailing list