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

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

92 lines
2.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
//===-- FifoFiles.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 "FifoFiles.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 {
FifoFile::FifoFile(StringRef path) : m_path(path) {}
FifoFile::~FifoFile() {
#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
unlink(m_path.c_str());
#endif
}
[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<std::shared_ptr<FifoFile>> CreateFifoFile(StringRef path) {
#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
return createStringError(inconvertibleErrorCode(), "Unimplemented");
#else
if (int err = mkfifo(path.data(), 0600))
return createStringError(std::error_code(err, std::generic_category()),
"Couldn't create fifo file: %s", path.data());
return std::make_shared<FifoFile>(path);
#endif
}
FifoFileIO::FifoFileIO(StringRef fifo_file, StringRef other_endpoint_name)
: m_fifo_file(fifo_file), m_other_endpoint_name(other_endpoint_name) {}
Expected<json::Value> FifoFileIO::ReadJSON(std::chrono::milliseconds timeout) {
// We use a pointer for this future, because otherwise its normal destructor
// would wait for the getline to end, rendering the timeout useless.
Optional<std::string> line;
std::future<void> *future =
new std::future<void>(std::async(std::launch::async, [&]() {
std::ifstream reader(m_fifo_file, std::ifstream::in);
std::string buffer;
std::getline(reader, buffer);
if (!buffer.empty())
line = buffer;
}));
if (future->wait_for(timeout) == std::future_status::timeout ||
!line.hasValue())
return createStringError(inconvertibleErrorCode(),
"Timed out trying to get messages from the " +
m_other_endpoint_name);
delete future;
return json::parse(*line);
}
Error FifoFileIO::SendJSON(const json::Value &json,
std::chrono::milliseconds timeout) {
bool done = false;
std::future<void> *future =
new std::future<void>(std::async(std::launch::async, [&]() {
std::ofstream writer(m_fifo_file, std::ofstream::out);
writer << JSONToString(json) << std::endl;
done = true;
}));
if (future->wait_for(timeout) == std::future_status::timeout || !done) {
return createStringError(inconvertibleErrorCode(),
"Timed out trying to send messages to the " +
m_other_endpoint_name);
}
delete future;
return Error::success();
}
} // namespace lldb_vscode