From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11409 invoked by alias); 23 Oct 2009 11:36:13 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 11397 invoked by uid 22791); 23 Oct 2009 11:36:13 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Message-ID: <4AE19522.5030206@redhat.com> Date: Fri, 23 Oct 2009 11:36:00 -0000 From: Phil Muldoon User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-2.7.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Project Archer Subject: [RFC] PR python/10826 Content-Type: multipart/mixed; boundary="------------010908090003060708010505" X-SW-Source: 2009-q4/txt/msg00023.txt.bz2 This is a multi-part message in MIME format. --------------010908090003060708010505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1425 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 PR python/10826 * python/python.c (gdbpy_write): Flush output. Testsuite ChangeLog 2009-10-23 Phil Muldoon * gdb.python/py-mi.exp: Regression test for PR python/10826. --------------010908090003060708010505 Content-Type: text/plain; name="gdb_write_flush.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gdb_write_flush.patch" Content-length: 847 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" --------------010908090003060708010505--