================
@@ -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);
+ });
----------------
ashgti wrote:
Adjusted the RedirectFD to clean up once the DAP object is not used anymore.
This includes making a best effort to use `dup2` to revert the FD redirects.
As for stderr handling, in server mode it no longer setups a redirect on stderr
to the current connection. When I allocate the SBDebugger I also configure the
OutputFile and ErrorFile handles to pipes that forward to that specific
connection.
This does mean that if we are running in a server mode and some part of lldb
(or llvm/clang/etc.) print directly to stderr then it wouldn't be associated
with the debug session, but I think that would be an issue for other users of
the SBDebugger API.
I know that Xcode also has a helper `lldb-rpc-server` that is a similar
configuration to the lldb-dap server mode. When a debug session starts in Xcode
it starts an `lldb-rpc-server` that hosts all the SBDebugger instances. So a
single version of Xcode will have 1 instance of `lldb-rpc-server` running at a
time and that instance is used to run each debug session for each Xcode window.
But my overall point with this is that if there are parts of the stack that are
not respecting the SBDebugger's OutputFile and ErrorFile it would also show up
in Xcode.
https://github.com/llvm/llvm-project/pull/116392
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
