From 8068751189af3099d9abef8953a9639d6798535c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= Date: Wed, 20 Jul 2022 16:27:21 +0200 Subject: [lldb] [gdb-remote] Refactor killing process and move it to client Refactor the code responsible for sending the "k" packet and move it into GDBRemoteCommunicationClient::KillProcess() method. This is part of refactoring to enable multiprocess support in the client, and to support using the vKill packet instead. As part of the refactoring, the following functional changes apply: - Some redundant logging has been removed, as any failures are returned via exit_string anyway. - SetLastStopPacket() is no longer called. It is used only to populate the thread list, and since the process has just exited and we're terminating the process instance, there's really no reason to set it. - On successful kill, exit_string is set to "killed", to clearly indicate that the process has terminated on our request rather than on its own. Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.llvm.org/D130340 --- .../Process/gdb-remote/ProcessGDBRemote.cpp | 68 ++++++++-------------- 1 file changed, 24 insertions(+), 44 deletions(-) (limited to 'lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp') diff --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp index 5f18706..3e1a6fb 100644 --- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp +++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp @@ -2394,7 +2394,6 @@ Status ProcessGDBRemote::DoDetach(bool keep_stopped) { } Status ProcessGDBRemote::DoDestroy() { - Status error; Log *log = GetLog(GDBRLog::Process); LLDB_LOGF(log, "ProcessGDBRemote::DoDestroy()"); @@ -2404,54 +2403,35 @@ Status ProcessGDBRemote::DoDestroy() { if (m_gdb_comm.IsConnected()) { if (m_public_state.GetValue() != eStateAttaching) { - StringExtractorGDBRemote response; - GDBRemoteCommunication::ScopedTimeout(m_gdb_comm, - std::chrono::seconds(3)); - - if (m_gdb_comm.SendPacketAndWaitForResponse("k", response, - GetInterruptTimeout()) == - GDBRemoteCommunication::PacketResult::Success) { - char packet_cmd = response.GetChar(0); + llvm::Expected kill_res = m_gdb_comm.KillProcess(GetID()); - if (packet_cmd == 'W' || packet_cmd == 'X') { + if (kill_res) { + exit_status = kill_res.get(); #if defined(__APPLE__) - // For Native processes on Mac OS X, we launch through the Host - // Platform, then hand the process off to debugserver, which becomes - // the parent process through "PT_ATTACH". Then when we go to kill - // the process on Mac OS X we call ptrace(PT_KILL) to kill it, then - // we call waitpid which returns with no error and the correct - // status. But amusingly enough that doesn't seem to actually reap - // the process, but instead it is left around as a Zombie. Probably - // the kernel is in the process of switching ownership back to lldb - // which was the original parent, and gets confused in the handoff. - // Anyway, so call waitpid here to finally reap it. - PlatformSP platform_sp(GetTarget().GetPlatform()); - if (platform_sp && platform_sp->IsHost()) { - int status; - ::pid_t reap_pid; - reap_pid = waitpid(GetID(), &status, WNOHANG); - LLDB_LOGF(log, "Reaped pid: %d, status: %d.\n", reap_pid, status); - } -#endif - SetLastStopPacket(response); - ClearThreadIDList(); - exit_status = response.GetHexU8(); - } else { - LLDB_LOGF(log, - "ProcessGDBRemote::DoDestroy - got unexpected response " - "to k packet: %s", - response.GetStringRef().data()); - exit_string.assign("got unexpected response to k packet: "); - exit_string.append(std::string(response.GetStringRef())); + // For Native processes on Mac OS X, we launch through the Host + // Platform, then hand the process off to debugserver, which becomes + // the parent process through "PT_ATTACH". Then when we go to kill + // the process on Mac OS X we call ptrace(PT_KILL) to kill it, then + // we call waitpid which returns with no error and the correct + // status. But amusingly enough that doesn't seem to actually reap + // the process, but instead it is left around as a Zombie. Probably + // the kernel is in the process of switching ownership back to lldb + // which was the original parent, and gets confused in the handoff. + // Anyway, so call waitpid here to finally reap it. + PlatformSP platform_sp(GetTarget().GetPlatform()); + if (platform_sp && platform_sp->IsHost()) { + int status; + ::pid_t reap_pid; + reap_pid = waitpid(GetID(), &status, WNOHANG); + LLDB_LOGF(log, "Reaped pid: %d, status: %d.\n", reap_pid, status); } +#endif + ClearThreadIDList(); + exit_string.assign("killed"); } else { - LLDB_LOGF(log, "ProcessGDBRemote::DoDestroy - failed to send k packet"); - exit_string.assign("failed to send the k packet"); + exit_string.assign(llvm::toString(kill_res.takeError())); } } else { - LLDB_LOGF(log, - "ProcessGDBRemote::DoDestroy - killed or interrupted while " - "attaching"); exit_string.assign("killed or interrupted while attaching."); } } else { @@ -2465,7 +2445,7 @@ Status ProcessGDBRemote::DoDestroy() { StopAsyncThread(); KillDebugserverProcess(); - return error; + return Status(); } void ProcessGDBRemote::SetLastStopPacket( -- cgit v1.1