================
@@ -32,35 +34,44 @@ using namespace lldb_dap;
namespace lldb_dap {
-DAP::DAP(llvm::StringRef path, ReplMode repl_mode)
- : debug_adaptor_path(path), broadcaster("lldb-dap"),
- exception_breakpoints(), focus_tid(LLDB_INVALID_THREAD_ID),
- stop_at_entry(false), is_attach(false),
+DAP::DAP(llvm::StringRef path, llvm::raw_ostream *log, ReplMode repl_mode,
+ std::vector<std::string> pre_init_commands)
+ : debug_adaptor_path(path), broadcaster("lldb-dap"), log(log),
+ exception_breakpoints(), pre_init_commands(pre_init_commands),
+ focus_tid(LLDB_INVALID_THREAD_ID), stop_at_entry(false),
is_attach(false),
enable_auto_variable_summaries(false),
enable_synthetic_child_debugging(false),
display_extended_backtrace(false),
restarting_process_id(LLDB_INVALID_PROCESS_ID),
configuration_done_sent(false), waiting_for_run_in_terminal(false),
progress_event_reporter(
[&](const ProgressEvent &event) { SendJSON(event.ToJSON()); }),
- reverse_request_seq(0), repl_mode(repl_mode) {
- const char *log_file_path = getenv("LLDBDAP_LOG");
-#if defined(_WIN32)
- // Windows opens stdout and stdin in text mode which converts \n to 13,10
- // while the value is just 10 on Darwin/Linux. Setting the file mode to
binary
- // fixes this.
- int result = _setmode(fileno(stdout), _O_BINARY);
- assert(result);
- result = _setmode(fileno(stdin), _O_BINARY);
- UNUSED_IF_ASSERT_DISABLED(result);
- assert(result);
-#endif
- if (log_file_path)
- log.reset(new std::ofstream(log_file_path));
-}
+ reverse_request_seq(0), repl_mode(repl_mode) {}
DAP::~DAP() = default;
+llvm::Error DAP::ConfigureIO(int out_fd, int err_fd) {
+ llvm::Expected<int> new_stdout_fd =
+ RedirectFd(out_fd, [this](llvm::StringRef data) {
+ SendOutput(OutputType::Stdout, data);
+ });
----------------
walter-erquinigo wrote:
Yeah, this is maybe the trickiest part of all. The redirection was introduced
to prevent LLDB proper from printing messages to stderr and unexpectedly
causing the DAP client to abort. And indeed, there are many parts of LLDB that
print directly to stderr upon unusual situations (dwarf parsing is one of them
IIRC). The ideal solution is to create an actual SB API that can handle these
unusual messages and print to stderr is simply the default behavior. You could
also do that.
If you don't do such refactor, something that you should consider when using
multiple connections simultaneously, is that it might be tricky to know which
of those stderr messages correspond to which DAP client. You might decide to
multicast them, which is better than sending the output to the wrong client.
Silencing the messages altogether might not be a good idea.
In any case, you can think of the redirection as something that needs to be set
up only once per process.
https://github.com/llvm/llvm-project/pull/116392
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
