llvm-project/lldb/tools/lldb-vscode/RunInTerminal.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

174 lines
5.9 KiB
C++
Raw Normal View History

[vscode] Improve runInTerminal and support linux Depends on D93874. runInTerminal was using --wait-for, but it was some problems because it uses process polling looking for a single instance of the debuggee: - it gets to know of the target late, which renders breakpoints in the main function almost impossible - polling might fail if there are already other processes with the same name - polling might also fail on some linux machine, as it's implemented with the ps command, and the ps command's args and output are not standard everywhere As a better way to implement this so that it works well on Darwin and Linux, I'm using now the following process: - lldb-vscode notices the runInTerminal, so it spawns lldb-vscode with a special flag --launch-target <target>. This flags tells lldb-vscode to wait to be attached and then it execs the target program. I'm using lldb-vscode itself to do this, because it makes finding the launcher program easier. Also no CMAKE INSTALL scripts are needed. - Besides this, the debugger creates a temporary FIFO file where the launcher program will write its pid to. That way the debugger will be sure of which program to attach. - Once attach happend, the debugger creates a second temporary file to notify the launcher program that it has been attached, so that it can then exec. I'm using this instead of using a signal or a similar mechanism because I don't want the launcher program to wait indefinitely to be attached in case the debugger crashed. That would pollute the process list with a lot of hanging processes. Instead, I'm setting a 20 seconds timeout (that's an overkill) and the launcher program seeks in intervals the second tepmorary file. Some notes: - I preferred not to use sockets because it requires a lot of code and I only need a pid. It would also require a lot of code when windows support is implemented. - I didn't add Windows support, as I don't have a windows machine, but adding support for it should be easy, as the FIFO file can be implemented with a named pipe, which is standard on Windows and works pretty much the same way. The existing test which didn't pass on Linux, now passes. Differential Revision: https://reviews.llvm.org/D93951
2020-12-29 04:00:47 +08:00
//===-- RunInTerminal.cpp ---------------------------------------*- C++ -*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "RunInTerminal.h"
#if !defined(_WIN32)
[vscode] Improve runInTerminal and support linux Depends on D93874. runInTerminal was using --wait-for, but it was some problems because it uses process polling looking for a single instance of the debuggee: - it gets to know of the target late, which renders breakpoints in the main function almost impossible - polling might fail if there are already other processes with the same name - polling might also fail on some linux machine, as it's implemented with the ps command, and the ps command's args and output are not standard everywhere As a better way to implement this so that it works well on Darwin and Linux, I'm using now the following process: - lldb-vscode notices the runInTerminal, so it spawns lldb-vscode with a special flag --launch-target <target>. This flags tells lldb-vscode to wait to be attached and then it execs the target program. I'm using lldb-vscode itself to do this, because it makes finding the launcher program easier. Also no CMAKE INSTALL scripts are needed. - Besides this, the debugger creates a temporary FIFO file where the launcher program will write its pid to. That way the debugger will be sure of which program to attach. - Once attach happend, the debugger creates a second temporary file to notify the launcher program that it has been attached, so that it can then exec. I'm using this instead of using a signal or a similar mechanism because I don't want the launcher program to wait indefinitely to be attached in case the debugger crashed. That would pollute the process list with a lot of hanging processes. Instead, I'm setting a 20 seconds timeout (that's an overkill) and the launcher program seeks in intervals the second tepmorary file. Some notes: - I preferred not to use sockets because it requires a lot of code and I only need a pid. It would also require a lot of code when windows support is implemented. - I didn't add Windows support, as I don't have a windows machine, but adding support for it should be easy, as the FIFO file can be implemented with a named pipe, which is standard on Windows and works pretty much the same way. The existing test which didn't pass on Linux, now passes. Differential Revision: https://reviews.llvm.org/D93951
2020-12-29 04:00:47 +08:00
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
#endif
#include <chrono>
#include <fstream>
#include <future>
#include <thread>
#include "llvm/Support/FileSystem.h"
#include "lldb/lldb-defines.h"
using namespace llvm;
namespace lldb_vscode {
const RunInTerminalMessagePid *RunInTerminalMessage::GetAsPidMessage() const {
return static_cast<const RunInTerminalMessagePid *>(this);
}
const RunInTerminalMessageError *
RunInTerminalMessage::GetAsErrorMessage() const {
return static_cast<const RunInTerminalMessageError *>(this);
}
RunInTerminalMessage::RunInTerminalMessage(RunInTerminalMessageKind kind)
: kind(kind) {}
RunInTerminalMessagePid::RunInTerminalMessagePid(lldb::pid_t pid)
: RunInTerminalMessage(eRunInTerminalMessageKindPID), pid(pid) {}
json::Value RunInTerminalMessagePid::ToJSON() const {
return json::Object{{"kind", "pid"}, {"pid", static_cast<int64_t>(pid)}};
}
RunInTerminalMessageError::RunInTerminalMessageError(StringRef error)
: RunInTerminalMessage(eRunInTerminalMessageKindError), error(error) {}
json::Value RunInTerminalMessageError::ToJSON() const {
return json::Object{{"kind", "error"}, {"value", error}};
}
RunInTerminalMessageDidAttach::RunInTerminalMessageDidAttach()
: RunInTerminalMessage(eRunInTerminalMessageKindDidAttach) {}
json::Value RunInTerminalMessageDidAttach::ToJSON() const {
return json::Object{{"kind", "didAttach"}};
}
static Expected<RunInTerminalMessageUP>
ParseJSONMessage(const json::Value &json) {
if (const json::Object *obj = json.getAsObject()) {
if (Optional<StringRef> kind = obj->getString("kind")) {
if (*kind == "pid") {
if (Optional<int64_t> pid = obj->getInteger("pid"))
return std::make_unique<RunInTerminalMessagePid>(
static_cast<lldb::pid_t>(*pid));
} else if (*kind == "error") {
if (Optional<StringRef> error = obj->getString("error"))
return std::make_unique<RunInTerminalMessageError>(*error);
} else if (*kind == "didAttach") {
return std::make_unique<RunInTerminalMessageDidAttach>();
}
}
}
return createStringError(inconvertibleErrorCode(),
"Incorrect JSON message: " + JSONToString(json));
}
static Expected<RunInTerminalMessageUP>
GetNextMessage(FifoFileIO &io, std::chrono::milliseconds timeout) {
if (Expected<json::Value> json = io.ReadJSON(timeout))
return ParseJSONMessage(*json);
else
return json.takeError();
}
static Error ToError(const RunInTerminalMessage &message) {
if (message.kind == eRunInTerminalMessageKindError)
return createStringError(inconvertibleErrorCode(),
message.GetAsErrorMessage()->error);
return createStringError(inconvertibleErrorCode(),
"Unexpected JSON message: " +
JSONToString(message.ToJSON()));
}
RunInTerminalLauncherCommChannel::RunInTerminalLauncherCommChannel(
StringRef comm_file)
: m_io(comm_file, "debug adaptor") {}
Error RunInTerminalLauncherCommChannel::WaitUntilDebugAdaptorAttaches(
std::chrono::milliseconds timeout) {
if (Expected<RunInTerminalMessageUP> message =
GetNextMessage(m_io, timeout)) {
if (message.get()->kind == eRunInTerminalMessageKindDidAttach)
return Error::success();
else
return ToError(*message.get());
} else
return message.takeError();
}
Error RunInTerminalLauncherCommChannel::NotifyPid() {
return m_io.SendJSON(RunInTerminalMessagePid(getpid()).ToJSON());
}
void RunInTerminalLauncherCommChannel::NotifyError(StringRef error) {
if (Error err = m_io.SendJSON(RunInTerminalMessageError(error).ToJSON(),
std::chrono::seconds(2)))
llvm::errs() << llvm::toString(std::move(err)) << "\n";
}
RunInTerminalDebugAdapterCommChannel::RunInTerminalDebugAdapterCommChannel(
StringRef comm_file)
: m_io(comm_file, "runInTerminal launcher") {}
// Can't use \a std::future<llvm::Error> because it doesn't compile on Windows
std::future<lldb::SBError>
RunInTerminalDebugAdapterCommChannel::NotifyDidAttach() {
[vscode] Improve runInTerminal and support linux Depends on D93874. runInTerminal was using --wait-for, but it was some problems because it uses process polling looking for a single instance of the debuggee: - it gets to know of the target late, which renders breakpoints in the main function almost impossible - polling might fail if there are already other processes with the same name - polling might also fail on some linux machine, as it's implemented with the ps command, and the ps command's args and output are not standard everywhere As a better way to implement this so that it works well on Darwin and Linux, I'm using now the following process: - lldb-vscode notices the runInTerminal, so it spawns lldb-vscode with a special flag --launch-target <target>. This flags tells lldb-vscode to wait to be attached and then it execs the target program. I'm using lldb-vscode itself to do this, because it makes finding the launcher program easier. Also no CMAKE INSTALL scripts are needed. - Besides this, the debugger creates a temporary FIFO file where the launcher program will write its pid to. That way the debugger will be sure of which program to attach. - Once attach happend, the debugger creates a second temporary file to notify the launcher program that it has been attached, so that it can then exec. I'm using this instead of using a signal or a similar mechanism because I don't want the launcher program to wait indefinitely to be attached in case the debugger crashed. That would pollute the process list with a lot of hanging processes. Instead, I'm setting a 20 seconds timeout (that's an overkill) and the launcher program seeks in intervals the second tepmorary file. Some notes: - I preferred not to use sockets because it requires a lot of code and I only need a pid. It would also require a lot of code when windows support is implemented. - I didn't add Windows support, as I don't have a windows machine, but adding support for it should be easy, as the FIFO file can be implemented with a named pipe, which is standard on Windows and works pretty much the same way. The existing test which didn't pass on Linux, now passes. Differential Revision: https://reviews.llvm.org/D93951
2020-12-29 04:00:47 +08:00
return std::async(std::launch::async, [&]() {
lldb::SBError error;
if (llvm::Error err =
m_io.SendJSON(RunInTerminalMessageDidAttach().ToJSON()))
error.SetErrorString(llvm::toString(std::move(err)).c_str());
return error;
[vscode] Improve runInTerminal and support linux Depends on D93874. runInTerminal was using --wait-for, but it was some problems because it uses process polling looking for a single instance of the debuggee: - it gets to know of the target late, which renders breakpoints in the main function almost impossible - polling might fail if there are already other processes with the same name - polling might also fail on some linux machine, as it's implemented with the ps command, and the ps command's args and output are not standard everywhere As a better way to implement this so that it works well on Darwin and Linux, I'm using now the following process: - lldb-vscode notices the runInTerminal, so it spawns lldb-vscode with a special flag --launch-target <target>. This flags tells lldb-vscode to wait to be attached and then it execs the target program. I'm using lldb-vscode itself to do this, because it makes finding the launcher program easier. Also no CMAKE INSTALL scripts are needed. - Besides this, the debugger creates a temporary FIFO file where the launcher program will write its pid to. That way the debugger will be sure of which program to attach. - Once attach happend, the debugger creates a second temporary file to notify the launcher program that it has been attached, so that it can then exec. I'm using this instead of using a signal or a similar mechanism because I don't want the launcher program to wait indefinitely to be attached in case the debugger crashed. That would pollute the process list with a lot of hanging processes. Instead, I'm setting a 20 seconds timeout (that's an overkill) and the launcher program seeks in intervals the second tepmorary file. Some notes: - I preferred not to use sockets because it requires a lot of code and I only need a pid. It would also require a lot of code when windows support is implemented. - I didn't add Windows support, as I don't have a windows machine, but adding support for it should be easy, as the FIFO file can be implemented with a named pipe, which is standard on Windows and works pretty much the same way. The existing test which didn't pass on Linux, now passes. Differential Revision: https://reviews.llvm.org/D93951
2020-12-29 04:00:47 +08:00
});
}
Expected<lldb::pid_t> RunInTerminalDebugAdapterCommChannel::GetLauncherPid() {
if (Expected<RunInTerminalMessageUP> message =
GetNextMessage(m_io, std::chrono::seconds(20))) {
if (message.get()->kind == eRunInTerminalMessageKindPID)
return message.get()->GetAsPidMessage()->pid;
return ToError(*message.get());
} else {
return message.takeError();
}
}
std::string RunInTerminalDebugAdapterCommChannel::GetLauncherError() {
// We know there's been an error, so a small timeout is enough.
if (Expected<RunInTerminalMessageUP> message =
GetNextMessage(m_io, std::chrono::seconds(1)))
return toString(ToError(*message.get()));
else
return toString(message.takeError());
}
Expected<std::shared_ptr<FifoFile>> CreateRunInTerminalCommFile() {
SmallString<256> comm_file;
if (std::error_code EC = sys::fs::getPotentiallyUniqueTempFileName(
"lldb-vscode-run-in-terminal-comm", "", comm_file))
return createStringError(EC, "Error making unique file name for "
"runInTerminal communication files");
return CreateFifoFile(comm_file.str());
}
} // namespace lldb_vscode