[lldb-dev] Windows lldb prompt issue
Greg Clayton via lldb-dev
lldb-dev at lists.llvm.org
Mon Mar 21 13:50:28 PDT 2016
You might see if there is some way to implement an equivalent of IOHandlerEditline that works on the windows terminal? Maybe a class like IOHandlerWindowsTerminal which would be specified to native windows terminal. There has to be a way to control the cursor and do line kind of commands. I believe that erase to beginning of line is all you would need to do to fix this correctly.
> On Mar 21, 2016, at 1:13 PM, Ted Woodward <ted.woodward at codeaurora.org> wrote:
>
> I dug into this some more. Windows is not using editline, so it's using the LLDB_DISABLE_LIBEDIT code path.
>
> IOHandlerEditline::GetLine() will print the prompt, then get the next line. Type in a command, and it will continue doing this. The prompt comes out before the command finishes (in this case, anyway), so we get the prompt, then the output from the command, then nothing.
>
> I've got a simple solution that works for hitting breakpoints and stepping, at least. In IOHandlerEditline::PrintAsync(), in the LLDB_DISABLE_LIBEDIT code path, print the prompt after calling IOHandler::PrintAsync().
>
> I'll put up a patch to phabricator.
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
>
> -----Original Message-----
> From: Greg Clayton [mailto:gclayton at apple.com]
> Sent: Monday, March 21, 2016 1:01 PM
> To: Ted Woodward <ted.woodward at codeaurora.org>
> Cc: LLDB <lldb-dev at lists.llvm.org>
> Subject: Re: [lldb-dev] Windows lldb prompt issue
>
> All input and output are handled by IOHandler subclasses. There is a stack of them. When you start LLDB you get one thing on the IOHandler stack: the LLDB command interpreter:
>
> IOHandlers:
> [0] IOHandlerEditline for command interpreter
>
> If you type "script" at the LLDB command prompt, the command interpreter pushes a IOHandlerPythonInterpreter onto the stack and all STDIN/OUT/ERR. Now your stack looks like:
>
> [0] IOHandlerEditline for command interpreter [1] IOHandlerPythonInterpreter
>
> When you type "quit()" in the IOHandlerPythonInterpreter, it will exit and pop off and return to:
>
> [0] IOHandlerEditline for command interpreter
>
> Note that these transitions happen on the same thread, so it is very easy to coordinate the output since it all happens in one thread of execution.
>
> When your process runs, by typing "run" on the command interpreter, the Process might push an IOHandler onto the stack so that when the process resumes you can do STDIN and receive any STDOUT/STDERR when your program runs, but it does so from _another_ thread. This is the only IOHandler that does things this way. So as soon as your resume a process that you have launched (if you attach, you don't get STDIN/OUT/ERR) we push the IOHandlerProcessSTDIO. When you stop, we must pop the IOHandlerProcessSTDIO. Again, this popping of the IOHandlerProcessSTDIO happens on another thread, not from the thread that is running the command interpreter. So this is why we have trouble coordinating the output. The threads the LLDB driver has are as follows:
>
> 1 - thread that runs the command interpreter
> 2 - thread that listens for debugger events (this includes process events for stops and runs)
> 3 - private process state thread that tracks any starts and stops and figure out when the send a public state change event
>
> Thread 3 might start and stop a process 10 times for one source level single step, but it will only send out one public eStateRunning event and one eStateStopped event. So when a public eStateStopped event get delivered from thread 3 to thread 2, we set off a chain of events where we must pop the
>
> So when a stopped event comes in, thread 2 receives the eStateStopped event and will handle flushing any pending STDOUT and STDERR and then pop the IOHandlerProcessSTDIO. When anyone wants to display text on the top IOHandler's output file, the must coordinate with the IOhandler stack. This is done by calling:
>
> void
> Debugger::PrintAsync (const char *s, size_t len, bool is_stdout);
>
> This coordinates with the top IOHandler by calling:
>
> void
> IOHandler::PrintAsync (Stream *stream, const char *s, size_t len);
>
> Now the command interpreter, when active will print its prompt of "(lldb) ". When async output comes in, it will eventually end up calling:
>
> void
> Editline::PrintAsync (Stream *stream, const char *s, size_t len) {
> Mutex::Locker locker(m_output_mutex);
> if (m_editor_status == EditorStatus::Editing)
> {
> MoveCursor(CursorLocation::EditingCursor, CursorLocation::BlockStart);
> fprintf(m_output_file, ANSI_CLEAR_BELOW);
> }
> stream->Write (s, len);
> stream->Flush();
> if (m_editor_status == EditorStatus::Editing)
> {
> DisplayInput();
> MoveCursor(CursorLocation::BlockEnd, CursorLocation::EditingCursor);
> }
> }
>
> This clears the current line, so it erases the "(lldb) ", prints the output in "stream", the it must refresh the current IOHandler, which for out command interpreter will restore the "(lldb) " prompt.
>
> So the question is: does the erase/print/restore feature in Editline::PrintAsync() even work on windows? I know that there is an Editline implementation on windows, but I am not sure it will do the right thing in this case as we are printing control characters to the screen in order to clear the "(lldb) " prompt with:
>
> if (m_editor_status == EditorStatus::Editing)
> {
> MoveCursor(CursorLocation::EditingCursor, CursorLocation::BlockStart);
> fprintf(m_output_file, ANSI_CLEAR_BELOW);
> }
>
> Then we write the "Stream" content. So after a very long story, you might better understand what is happening. It would be worth testing something on windows where you just call Debugger::PrintAsync() while the "(lldb) " prompt is up and on the screen and see what happens. If this isn't working, then we know why the issue is happening. So if you have the following displayed in the LLDB driver:
>
> "(lldb) "
>
> And you call "Debugger::PrintAsync("hello world\n", 12, true)" on a thread that is not thread 1 from the initial thread list shown at the beginning, you should see your screen be:
>
> "hello world
> (lldb) "
>
> If you see:
>
> "(lldb)
> hello world
> (lldb) "
>
> Then you know that the erasing feature isn't working in Editline::PrintAsync() and it will explain why you see this issue.
>
> Greg Clayton
>
>> On Mar 21, 2016, at 10:10 AM, Ted Woodward via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>
>> I run lldb on Windows and Linux, launching my gdb-server based Hexagon simulator automatically on a process launch. On Windows I’m seeing the (lldb) prompt before the stop message, and no prompt after. On Linux I see the prompt after.
>>
>> Windows:
>> Current executable set to 'u:\lldb_test\factwin' (hexagon).
>> (lldb) b main
>> Breakpoint 1: where = factwin`main + 28 at factorial.c:32, address =
>> 0x00005130
>> (lldb) r
>> Process 1 launched: 'u:\lldb_test\factwin' (hexagon)
>> (lldb) Process 1 stopped
>> * thread #1: tid = 0x0001, 0x00005130 factwin`main(argc=1, argv=0x0000e110) + 28 at factorial.c:32, stop reason = breakpoint 1.1
>> frame #0: 0x00005130 factwin`main(argc=1, argv=0x0000e110) + 28 at factorial.c:32
>> 29 }
>> 30 */
>> 31
>> -> 32 base = 10;
>> 33
>> 34 printf("Factorial of %d is %d\n", base, factorial(base));
>> 35 return 0;
>>
>>
>> Linux:
>> Current executable set to '/usr2/tedwood/lldb_test/factorial' (hexagon).
>> (lldb) b main
>> Breakpoint 1: where = factorial`main + 28 at factorial.c:32, address =
>> 0x00004130
>> (lldb) r
>> Process 1 launched: '/usr2/tedwood/lldb_test/factorial' (hexagon)
>> Process 1 stopped
>> * thread #1: tid = 0x0001, 0x00004130 factorial`main(argc=1, argv=0x0000b100) + 28 at factorial.c:32, stop reason = breakpoint 1.1
>> frame #0: 0x00004130 factorial`main(argc=1, argv=0x0000b100) + 28 at factorial.c:32
>> 29 }
>> 30 */
>> 31
>> -> 32 base = 10;
>> 33
>> 34 printf("Factorial of %d is %d\n", base, factorial(base));
>> 35 return 0;
>> (lldb)
>>
>>
>>
>> Any idea why the prompt is coming out before the stop message?
>>
>>
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
More information about the lldb-dev
mailing list