[all-commits] [llvm/llvm-project] 64f47c: [lldb-vscode] redirect stderr/stdout to the IDE's ...

[walter erquinigo via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 64f47c1e58a10de160ce3fb3afbc50c0243e2977
      https://github.com/llvm/llvm-project/commit/64f47c1e58a10de160ce3fb3afbc50c0243e2977
  Author: Walter Erquinigo <a20012251 at gmail.com>
  Date:   2021-04-21 (Wed, 21 Apr 2021)

  Changed paths:
    M lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
    M lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
    A lldb/test/API/tools/lldb-vscode/console/TestVSCode_redirection_to_console.py
    M lldb/tools/lldb-vscode/CMakeLists.txt
    M lldb/tools/lldb-vscode/IOStream.cpp
    A lldb/tools/lldb-vscode/OutputRedirector.cpp
    A lldb/tools/lldb-vscode/OutputRedirector.h
    M lldb/tools/lldb-vscode/lldb-vscode.cpp

  Log Message:
  -----------
  [lldb-vscode] redirect stderr/stdout to the IDE's console

In certain occasions times, like when LLDB is initializing and
evaluating the .lldbinit files, it tries to print to stderr and stdout
directly. This confuses the IDE with malformed data, as it talks to
lldb-vscode using stdin and stdout following the JSON RPC protocol. This
ends up terminating the debug session with the user unaware of what's
going on. There might be other situations in which this can happen, and
they will be harder to debug than the .lldbinit case.

After several discussions with @clayborg, @yinghuitan and @aadsm, we
realized that the best course of action is to simply redirect stdout and
stderr to the console, without modifying LLDB itself. This will prove to
be resilient to future bugs or features.

I made the simplest possible redirection logic I could come up with. It
only works for POSIX, and to make it work with Windows should be merely
changing pipe and dup2 for the windows equivalents like _pipe and _dup2.
Sadly I don't have a Windows machine, so I'll do it later once my office
reopens, or maybe someone else can do it.

I'm intentionally not adding a stop-redirecting logic, as I don't see it
useful for the lldb-vscode case (why would we want to do that, really?).

I added a test.

Note: this is a simpler version of D80659. I first tried to implement a
RIIA version of it, but it was problematic to manage the state of the
thread and reverting the redirection came with some non trivial
complexities, like what to do with unflushed data after the debug
session has finished on the IDE's side.