[RFC] PR python/10826

[RFC] PR python/10826

[Phil Muldoon]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

I've attached a patch to what I think is the best fix for the PR.  
Before the patch, "gdb.write" wrote to gdb_stdout and exited. The 
completion was noted, and MI appended "^done". While the command had 
indeed finished, the output was still still lurking in gdb_stdout, and 
was being flushed out later. This lead to out-of-sequence ^done message 
and "gdb.write" output.  I talked with Andre and Vlad on irc about 
possible fixes. We talked about the MI code flushing the buffer before 
appending ^done, but we are just not sure if this is correct. Given that 
many front ends presumably rely on the current MI expectation that each 
function flushes its own CLI output before exiting, the next best thing 
would be have gdb.write do just that.  This however does not allow large 
CLI messages to be constructed (or cached I guess) in gdb_stdout with 
successive calls to "gdb.write" - each write is flushed at the end of 
each "gdb.write" call. The workaround for this is to construct your 
message in some other buffer then feed the entire buffer to gdb.write at 
the end.

Anyway, here is the patch and test.

What do you think?

Cheers,

Phil

--

ChangeLog

2009-10-23  Phil Muldoon <pmuldoon@redhat.com>

     PR python/10826

     * python/python.c (gdbpy_write): Flush output.

Testsuite ChangeLog

2009-10-23  Phil Muldoon <pmuldoon@redhat.com>

     * gdb.python/py-mi.exp: Regression test for PR python/10826.


[-- Attachment #2: gdb_write_flush.patch --]
[-- Type: text/plain, Size: 847 bytes --]

diff --git a/gdb/python/python.c b/gdb/python/python.c
index 707b700..33c1bae 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -567,6 +567,7 @@ gdbpy_write (PyObject *self, PyObject *args)
   if (! PyArg_ParseTuple (args, "s", &arg))
     return NULL;
   printf_filtered ("%s", arg);
+  gdb_flush (gdb_stdout);
   Py_RETURN_NONE;
 }
 
diff --git a/gdb/testsuite/gdb.python/py-mi.exp b/gdb/testsuite/gdb.python/py-mi.exp
index 30d6f32..5b7c4e9 100644
--- a/gdb/testsuite/gdb.python/py-mi.exp
+++ b/gdb/testsuite/gdb.python/py-mi.exp
@@ -232,3 +232,7 @@ mi_continue_to_line \
     "step to second breakpoint"
 
 mi_varobj_update_with_type_change container int 0 "update after type change"
+
+mi_gdb_test "-interpreter-exec console \"python gdb.write (str(42))\"" \
+  ".*\~\\\"42\\\".*\\^done" \
+  "ensure gdb write output is flushed"

Re: [RFC] PR python/10826

[Tom Tromey]

>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:

Phil> I've attached a patch to what I think is the best fix for the PR.

Phil> What do you think?

AFAIK, we require gdb commands to flush their output or emit a newline.
Why not also require this of Python scripts?  IOW, I think we should
probably just close this as invalid.

Tom

Re: [RFC] PR python/10826

[Phil Muldoon]

On 10/30/2009 10:20 PM, Tom Tromey wrote:
>>>>>> "Phil" == Phil Muldoon<pmuldoon@redhat.com>  writes:
>>>>>>              
> Phil>  I've attached a patch to what I think is the best fix for the PR.
>
> Phil>  What do you think?
>
> AFAIK, we require gdb commands to flush their output or emit a newline.
> Why not also require this of Python scripts?  IOW, I think we should
> probably just close this as invalid.
>
> Tom
>    

I updated the bug (and closed it) with a link to these comments, and 
also a canned command demonstrating the .flush()/new-line output in MI

Thanks for the review!

http://sourceware.org/bugzilla/show_bug.cgi?id=10826

Cheers,

Phil