Yea Windows does have methods for doing this, it's just windows specific as you said and requires someone to actually do it.
On Mon, Mar 21, 2016 at 1:50 PM Greg Clayton <gclay...@apple.com> wrote: > 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.woodw...@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:gclay...@apple.com] > > Sent: Monday, March 21, 2016 1:01 PM > > To: Ted Woodward <ted.woodw...@codeaurora.org> > > Cc: LLDB <lldb-dev@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@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@lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
