From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10004 invoked by alias); 19 Feb 2019 22:12:29 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 9993 invoked by uid 89); 19 Feb 2019 22:12:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:1245, customer X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Feb 2019 22:12:28 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 03E21C0669BB; Tue, 19 Feb 2019 22:12:27 +0000 (UTC) Received: from f29-4.lan (ovpn-117-11.phx2.redhat.com [10.3.117.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CA0A019C57; Tue, 19 Feb 2019 22:12:26 +0000 (UTC) Date: Tue, 19 Feb 2019 22:12:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: Re: [PATCH] Remove excess calls to gdb_flush Message-ID: <20190219151226.2805c624@f29-4.lan> In-Reply-To: <20190219205426.4168-1-tromey@adacore.com> References: <20190219205426.4168-1-tromey@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00315.txt.bz2 On Tue, 19 Feb 2019 13:54:26 -0700 Tom Tromey wrote: > A customer noticed some mildly odd MI output, where CLI output was > split into multiple MI strings at unusual boundaries, like this: > > ~"$1 = (b => true" > ~", p => 0x407260" > > This is technically correct according to the MI spec, but still > unusual, in that there's no particular reason for the string to be > split where it is. > > I tracked this down to a call to gdb_flush in generic_val_print. > Then, I went through all calls to gdb_flush and removed the ones I > thought were superfluous. In particular: > > * Any call in the value-printing code; > * Likewise the type-printing code (just a single call); and > * Any call that immediately followed a printf that obviously > ended with a newline, my belief being that gdb's standard output > streams are line buffered (by inheriting the behavior from stdio) > > Regression tested on x86-64 Fedora 29. > > I didn't add a new test case. I tend to think we don't necessarily > want to specify this behavior in the tests. Let me know what you > think of this. I agree with you regarding the test case. I looked over the patch and didn't see any problems. Kevin