[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
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2021-01-28 05:02:45 +08:00
|
|
|
#include "FifoFiles.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 {
|
|
|
|
|
|
|
|
FifoFile::FifoFile(StringRef path) : m_path(path) {}
|
|
|
|
|
|
|
|
FifoFile::~FifoFile() {
|
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
|
|
|
unlink(m_path.c_str());
|
|
|
|
#endif
|
2021-02-01 19:45:07 +08:00
|
|
|
}
|
[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) {
|
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
|
|
|
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
|