From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9384 invoked by alias); 15 Aug 2013 17:36:27 -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 9374 invoked by uid 89); 15 Aug 2013 17:36:27 -0000 X-Spam-SWARE-Status: No, score=-50.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE autolearn=ham version=3.3.2 Received: from mho-03-ewr.mailhop.org (HELO mho-01-ewr.mailhop.org) (204.13.248.66) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 15 Aug 2013 17:36:25 +0000 Received: from pool-173-48-46-190.bstnma.fios.verizon.net ([173.48.46.190] helo=cgf.cx) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1VA1TB-0002Fj-6U; Thu, 15 Aug 2013 17:36:21 +0000 Received: from localhost (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id B07B660117; Thu, 15 Aug 2013 13:36:18 -0400 (EDT) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18cAtWO1nVdPYHssZOGWxFf Date: Thu, 15 Aug 2013 17:36:00 -0000 From: Christopher Faylor To: palves@redhat.com, gdb-patches@sourceware.org, yao@codesourcery.com, Joel Brobecker , Eli Zaretskii Subject: Re: [PATCH] Unbuffer stdout and stderr on windows Message-ID: <20130815173618.GA6955@ednor.casa.cgf.cx> Mail-Followup-To: palves@redhat.com, gdb-patches@sourceware.org, yao@codesourcery.com, Joel Brobecker , Eli Zaretskii References: <1374462417-7961-1-git-send-email-yao@codesourcery.com> <838v0yy556.fsf@gnu.org> <51EE23F8.1070905@codesourcery.com> <83wqohw4ee.fsf@gnu.org> <20130729192559.GA5348@ednor.casa.cgf.cx> <83d2q1xiyv.fsf@gnu.org> <51F6C7B2.3020400@redhat.com> <20130731034045.GA5565@ednor.casa.cgf.cx> <20130812211105.GA11128@adacore.com> <8361v9piop.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8361v9piop.fsf@gnu.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2013-08/txt/msg00400.txt.bz2 On Tue, Aug 13, 2013 at 09:08:38PM +0300, Eli Zaretskii wrote: >> Date: Mon, 12 Aug 2013 14:11:05 -0700 >> From: Joel Brobecker >> >> > We had a somewhat heated debate in the cygwin list about using the >> > techniques in winpty and eventually abandoned the idea because the way >> > things like winpty create consoles is not foolproof. Since it relies on >> > polling, it is theoretically possible to lose data. >> > >> > I'll bet that, in practice you'd never see any data loss, though. >> > And, from that observation, you can see which side of the argument >> > I was on. :-) >> >> FWIW, many frontends also implements communication with GDB using >> pipes on Windows, and running MinGW-gdb inside cygwin window/shell >> is just a very very common practice, regardless of whether officially >> supported or not. How does Emacs do, for instance? IIRC when I looked >> at the code, that's what it did. > >Yes, Emacs does that. But it is never a problem in that case, because >it's the user who looks at the results, not a program that wants to >interpret them. > >> Having the stdout/stderr output mixed up is very confusing and breaks >> testing as well, so we applied the same approach as Yao's at AdaCore. > >Making GDB output unbuffered is not a good idea for Emacs, because it >will cause it read single characters, which is (a) inefficient, and >(b) error-prone, because a single CR character could dupe the text >decoding routines into thinking the EOL format is from Mac. I thought that "unbuffered" normally means something like "every output operation gets immediately sent as a block" rather than "flush after every character". If the mingw "unbuffered" mode means that everything is o n e c h a r a c t e r a t a t i m e, then that would obviously not be an acceptable solution. Or, maybe this is just the way emacs itself works. The other alternative would be to use line buffering for gdb. I don't see why cygwin pipes (whether they are "ptys" or actual pipes) are a special case here. stdout is usually line buffered isn't it? Why not just force that behavior for gdb? cgf