Fix for missing prompt on Windows

[ted]

Summary

On Windows (and possibly other hosts with LLDB_DISABLE_LIBEDIT defined), the (lldb) prompt won't print after async output, like from a breakpoint hit or a step. This patch forces the prompt to be printed out after async output.

[clayborg]

Looks fine.

[amccarth]

This just seems to insert an extra prompt rather than solving the problem with the prompt being printed too late.

[clayborg]

No, this fixed the problem of printing the "(lldb) " prompt first, then being asked to print async text, then not refreshing the prompt. Not to say there won't still be a race, but this particular problem is what we are fixing.

[amccarth]

I patched this change in, and now I'm getting extra prompts on Windows rather than getting the too-late prompt sooner. So is that a separate bug?

[clayborg]

It would be nice to clear the line though. What _should_ happen is the "(lldb) " prompt is cleared by clearing text to the start of where the prompt was printed, then display the async text and refresh the prompt. So this fix is a bit hacky in that it isn't trying to solve the clearing of the prompt, it will just display it twice. If you start with:

(lldb)

Then get async text of "async text here\n". On windows you would now get:

(lldb)
async text here
(lldb)

Instead of the correct behavior in editline:

async text here
(lldb)

as it would have backed up over the prompt before displaying the async text.

[clayborg]

this could still be the same bug. So if this doesn't fix things for you on windows, then this bug isn't quite fixed. Ted, are you seeing the same thing? amccarth, can you attach some output to see what you are seeing?

[amccarth]

Here's a snippet of output with this fix patched in on Windows. Note the extra (lldb) prompts on the lines beginning with "Process 10672..."

(lldb) br set -l 22
Breakpoint 1: where = a.exe`main + 20 at fizzbuzz.cpp:22, address = 0x0040e074
(lldb) run
Process 10672 launching
(lldb) Process 10672 launched: 'd:\src\fizzbuzz\a.exe' (i686)
(lldb) Process 10672 stopped

• thread #1: tid = 0x43c8, 0x00e4e074 a.exe`main + 20 at fizzbuzz.cpp:22, stop reason = breakpoint 1.1 frame #0: 0x00e4e074 a.exe`main + 20 at fizzbuzz.cpp:22 19 { 20 int *buggy = 0; 21

-> 22 for (int i = 1; i <= 100; ++i)

23       {
24           if (fizz(i)) std::cout << "fizz";
25           if (buzz(i)) std::cout << "buzz";

(lldb)

Without this patch, those extra prompts are not there, but neither is the final prompt. So it's broken both with and without this patch. With the patch is arguably better than without.

[clayborg]

Seems like it would be nice to get the prompt clearing working...

[ted]

Without the patch I'm seeing the original prompt printed after the command, in a line like this:

(lldb) Process 1 stopped

and no prompt after the async output from the stop.

With the patch I see the above prompt, and a prompt after the async output. I think with the patch is better, but we do need to remove the original prompt.

There's a Windows EditLine implementation at http://mingweditline.sourceforge.net/ that builds with VS2010; it might work with 2013/2015.

[ted]

Updated to change cursor position before async output so old prompt is overwritten.

Adrian, please test with your setup and let me know if it solves the issues you see.

[amccarth]

This is better. In the same scenario, I see just one extra prompt instead of three extras. Maybe that one happens through a different code path.

(lldb) br set -l 22
Breakpoint 1: where = a.exe`main + 20 at fizzbuzz.cpp:22, address = 0x0040e074
(lldb) run
Process 13268 launching
(lldb) Process 13268 launched: 'd:\src\fizzbuzz\a.exe' (i686)
Process 13268 stopped

The extra one remains between "Process xx launching" and "Process xx launched."

[ted]

Adrian and I worked out what is going on:

1. Run starts the launch and writes a prompt
2. State change fires, prints out “launching” through async, overwriting the prompt from 1) and writing a new prompt
3. CommandObjectProcessLaunch::Execute appends “launch” to the result. The result gets printed, after the prompt from 2)
4. State change fires, prints out “stopped” through async, overwriting no prompt because we’re on a fresh line and writing a new prompt

I think the only way to fix this is to copy the Windows specific code from IOHandlerEditLine::PrintAsync to CommandObjectProcessLaunch::Execute. Adrian and I don't want to add platform specific code to CommandObjectProcessLaunch, and this fix is a major improvement, so we'll go with this version.

[clayborg]

Sounds good. This code is very tricky and we need to find a way to control this so that these issues never happen. When we do this, it will hopefully fix these kinds of issues for everyone. Thanks for taking the extra time to look into it and at least you have made the windows experience much better than it used to be.

source/Core/IOHandler.cpp

 #include "lldb/Target/StackFrame.h"
 #endif
 
+#ifdef _MSC_VER
+#include <Windows.h>
+#endif
+
 using namespace lldb;
 using namespace lldb_private;
 

         m_editline_ap->PrintAsync(stream, s, len);
     else
 #endif
+    {
+        const char *prompt = GetPrompt();
+#ifdef _MSC_VER
+        if (prompt)
+        {
+            // Back up over previous prompt using Windows API
+            CONSOLE_SCREEN_BUFFER_INFO screen_buffer_info;
+            HANDLE console_handle = GetStdHandle(STD_OUTPUT_HANDLE);
+            GetConsoleScreenBufferInfo(console_handle, &screen_buffer_info);
+            COORD coord = screen_buffer_info.dwCursorPosition;
+            coord.X -= strlen(prompt);
+            if (coord.X < 0)
+                coord.X = 0;
+            SetConsoleCursorPosition(console_handle, coord);
+        }
+#endif
         IOHandler::PrintAsync(stream, s, len);
+        if (prompt)
+            IOHandler::PrintAsync(GetOutputStreamFile().get(), prompt, strlen(prompt));
+    }
 }
 
 // we may want curses to be disabled for some builds