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.
You must use None instead of {} otherwise all callers to this function will share the default dictionary