[Lldb-commits] [lldb] r181807 - <rdar://problem/13764135>
Greg Clayton
gclayton at apple.com
Tue May 14 15:09:47 PDT 2013
I was guessing this was going to fix the linux issues after thinking about the threading implications I noticed when I found the source of the bug!
I am glad to see hear that it has made it more reliable!!
On May 14, 2013, at 2:10 PM, "Kopec, Matt" <matt.kopec at intel.com> wrote:
> Hi Greg,
>
> The lldb Linux prompt seems to be working much better (ie. no missing prompts), at least for me anyway. Thanks!
>
> Have you tried this commit on your Linux machine?
>
> Matt
>
> On 2013-05-14, at 1:36 PM, Greg Clayton <gclayton at apple.com> wrote:
>
>> Author: gclayton
>> Date: Tue May 14 12:36:51 2013
>> New Revision: 181807
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=181807&view=rev
>> Log:
>> <rdar://problem/13764135>
>>
>> The "lldb" driver was interfering with STDOUT and STDERR if the output was over 1024 charcters long. The output was grabbing 1024 characters at a time, before it output the characters, it was writing characters to the screen to clear the current line. This has been fixed.
>>
>> I also fixed the command interpreter from mixing the "(lldb) " prompt in with program output by always manually checking for program output. This was done by having the command interpreter know when it is in the middle of executing a command by setting a bool. This was needed since sometimes when a command would run the target, like with a command like 'expression (int)printf("hello\n")', the process would push a new input reader, and then pop it when it was done. This popping of the input reader would cause the command interpreter to get sent a reactivated message (from the private process state thread) and cause it to ask for another command, even though we were still in the middle of the command ('expression (int)printf("hello\n")'). Now we set a bool to true, run the command and set the bool to false. If we get reactivated while we are in the middle of a command, we don't say we are ready for a new command. This coupled with emitting the STDOUT/STDERR first after each!
co!
>> mmand, fo
>> llowed by the command results, followed by then saying we are ready for a new command, should help cleanup the command line output on all platforms.
>>
>>
>> Modified:
>> lldb/trunk/tools/driver/Driver.cpp
>> lldb/trunk/tools/driver/Driver.h
>>
>> Modified: lldb/trunk/tools/driver/Driver.cpp
>> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/driver/Driver.cpp?rev=181807&r1=181806&r2=181807&view=diff
>> ==============================================================================
>> --- lldb/trunk/tools/driver/Driver.cpp (original)
>> +++ lldb/trunk/tools/driver/Driver.cpp Tue May 14 12:36:51 2013
>> @@ -120,6 +120,7 @@ Driver::Driver () :
>> m_editline_reader (),
>> m_io_channel_ap (),
>> m_option_data (),
>> + m_executing_user_command (false),
>> m_waiting_for_command (false),
>> m_done(false)
>> {
>> @@ -775,7 +776,7 @@ Driver::GetProcessSTDOUT ()
>> size_t total_bytes = 0;
>> while ((len = m_debugger.GetSelectedTarget().GetProcess().GetSTDOUT (stdio_buffer, sizeof (stdio_buffer))) > 0)
>> {
>> - m_io_channel_ap->OutWrite (stdio_buffer, len, ASYNC);
>> + m_io_channel_ap->OutWrite (stdio_buffer, len, NO_ASYNC);
>> total_bytes += len;
>> }
>> return total_bytes;
>> @@ -790,7 +791,7 @@ Driver::GetProcessSTDERR ()
>> size_t total_bytes = 0;
>> while ((len = m_debugger.GetSelectedTarget().GetProcess().GetSTDERR (stdio_buffer, sizeof (stdio_buffer))) > 0)
>> {
>> - m_io_channel_ap->ErrWrite (stdio_buffer, len, ASYNC);
>> + m_io_channel_ap->ErrWrite (stdio_buffer, len, NO_ASYNC);
>> total_bytes += len;
>> }
>> return total_bytes;
>> @@ -1069,17 +1070,28 @@ Driver::HandleIOEvent (const SBEvent &ev
>>
>> // We don't want the result to bypass the OutWrite function in IOChannel, as this can result in odd
>> // output orderings and problems with the prompt.
>> +
>> + // Note that we are in the process of executing a command
>> + m_executing_user_command = true;
>> +
>> m_debugger.GetCommandInterpreter().HandleCommand (command_string, result, true);
>>
>> + // Note that we are back from executing a user command
>> + m_executing_user_command = false;
>> +
>> + // Display any STDOUT/STDERR _prior_ to emitting the command result text
>> + GetProcessSTDOUT ();
>> + GetProcessSTDERR ();
>> +
>> const bool only_if_no_immediate = true;
>>
>> + // Now emit the command output text from the command we just executed
>> const size_t output_size = result.GetOutputSize();
>> -
>> if (output_size > 0)
>> m_io_channel_ap->OutWrite (result.GetOutput(only_if_no_immediate), output_size, NO_ASYNC);
>>
>> + // Now emit the command error text from the command we just executed
>> const size_t error_size = result.GetErrorSize();
>> -
>> if (error_size > 0)
>> m_io_channel_ap->OutWrite (result.GetError(only_if_no_immediate), error_size, NO_ASYNC);
>>
>> @@ -1149,7 +1161,8 @@ Driver::EditLineInputReaderCallback
>> break;
>>
>> case eInputReaderReactivate:
>> - driver->ReadyForCommand();
>> + if (driver->m_executing_user_command == false)
>> + driver->ReadyForCommand();
>> break;
>>
>> case eInputReaderDeactivate:
>>
>> Modified: lldb/trunk/tools/driver/Driver.h
>> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/driver/Driver.h?rev=181807&r1=181806&r2=181807&view=diff
>> ==============================================================================
>> --- lldb/trunk/tools/driver/Driver.h (original)
>> +++ lldb/trunk/tools/driver/Driver.h Tue May 14 12:36:51 2013
>> @@ -162,6 +162,7 @@ private:
>> lldb::SBInputReader m_editline_reader;
>> std::unique_ptr<IOChannel> m_io_channel_ap;
>> OptionData m_option_data;
>> + bool m_executing_user_command;
>> bool m_waiting_for_command;
>> bool m_done;
>>
>>
>>
>> _______________________________________________
>> lldb-commits mailing list
>> lldb-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>
More information about the lldb-commits
mailing list