[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
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2021-01-29 01:24:30 +08:00
|
|
|
#include "RunInTerminal.h"
|
|
|
|
|
2021-02-05 02:07:07 +08:00
|
|
|
#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") {}
|
|
|
|
|
2021-01-26 06:05:04 +08:00
|
|
|
// 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, [&]() {
|
2021-01-26 06:05:04 +08:00
|
|
|
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
|