[ConPTY] Avoid screen clear when starting process

[Nerixyz (Nerixyz)]

In LLDB, we've been moving towards using the ConPTY to show the output of processes inline instead of a new console window:

> lldb demo.exe
...
(lldb) r
Hello World
^ would show in a new console window before
Process 1337 exited with status = 0 (0x00000000)

When starting the process and reading from the PTY, we always get the VT init-sequence that clears the screen and sets the window title (from the EchoCon example):

"\u{1b}[?9001h\u{1b}[?1004h"
"\u{1b}[?25l\u{1b}[2J\u{1b}[m\u{1b}[H\u{1b}]0;C:\\WINDOWS\\SYSTEM32\\ping.exe\u{7}\u{1b}[?25h"
"\r\nPinging
....(some output)....
Average = 0ms\r\n\u{1b}[?25h"
"\u{1b}[?9001l\u{1b}[?1004l"

• \u{1b}[?9001h: enable win32-input-mode
• \u{1b}[?1004h: send Focus In/Out events
• \u{1b}[?25l: hide cursor
• \u{1b}[2J: selective erase all
• \u{1b}[m: set default character attributes (VT100)
• \u{1b}[H: set cursor to (1,1)
• \u{1b}]0;C:\\WINDOWS\\SYSTEM32\\ping.exe\u{7}: set window title
• \u{1b}[?25h: show cursor
• output...
• \u{1b}[?9001l: disable win32-input-mode
• \u{1b}[?1004h: don't send Focus In/Out events

For LLDB, we'd like to avoid parts of the init sequence - we want to show the output of the process directly after the (lldb) r prompt. Our current solution is to filter out the sequence when starting the process.

If LLDB does not strip the init sequence, after the user runs the debuggee (r command), this is what the console window looks like:

Before running

(lldb) r

After running

Hello World
Process 1337 exited with status = 0 (0x00000000)

The (lldb) r prompt is overwritten.
Running the debuggee should not clear the screen, instead the screen should look like this:

Before running

(lldb) r

After running

(lldb) r
Hello World
Process 1337 exited with status = 0 (0x00000000)

Would it be possible to tell the pseudo-console API which parts we'd like to get or to omit some parts?

[Mukunda Rao Katta (MukundaKatta)]

The \u{1b}[2J clear is part of ConPTY's standard init sequence — it's resetting the VT emulator state on attach. For inline output you don't want that. Two options: attach with PSEUDOCONSOLE_INHERIT_CURSOR flag on CreatePseudoConsole (preserves the caller's cursor/screen state and skips the clear), or filter the init sequence out in LLDB before forwarding to the terminal. The inherit-cursor flag landed in Windows 10 1903+ and is what conhost's own inline modes use.

[Dustin L. Howett (DHowett)]

The previous answer on this thread is correct. But... if you're going to give the spawned subprocess access to the console, why not just run it with standard console inheritance? Does lldb use a PTY on other platforms?

[Charles Zablit (charles-zablit)]

Thanks for the answers! To add more details:
On other platforms, lldb reads from a PTY and stores the stdout/stderr in a buffer, on a separate thread. This is because lldb interlaces its output with the process’ output. Debugging a hello world program looks like this:

lldb.exe main.exe
(lldb) target create "C:
main.exe"
Current executable set to ‘C:\main.exe' (x86_64).
(lldb) run
Process 38076 launched: ‘C:\main.exe' (x86_64)
Hello World!
Process 38076 exited with status = 0 (0x00000000)
(lldb) exit

From my understanding, lldb cannot use standard console inheritance because we could not control how the output of lldb and the output of the debuggee would overlap. At the time, this was also for architecture reasons, to match what is already implemented in lldb on other platforms than Windows.
I was also under the impression that debugging a TUI program would not work properly in lldb if we were to use console inheritance, for the same reasons.
It’s worth noting that we are able to use standard console inheritance in the “internalConsole” mode of lldb-dap, because it does not handle VT sequences at all.
In the places were we do use the ConPTY, we followed the previous advice of using PSEUDOCONSOLE_INHERIT_CURSOR: https://github.com/llvm/llvm-project/blob/268bac6c2519a94f4ae515e2db540adf7f368621/lldb/source/Host/windows/PseudoConsole.cpp#L146. This has worked well so far.
We are having a hard time synchronizing lldb’s main thread with the read thread of the ConPTY: we could not figure out a reliable mechanism for checking that the ConPTY’s output pipe is empty. When the debuggee stops on a breakpoint, we need to wait for all the output of the ConPTY to be read by the read thread. How much time we need to wait is unknown, and we had to come up with a heuristic: https://github.com/llvm/llvm-project/pull/194422/changes.