From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16348 invoked by alias); 13 Aug 2013 18:08:18 -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 16338 invoked by uid 89); 13 Aug 2013 18:08:17 -0000 X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,RCVD_IN_NIX_SPAM,SPF_SOFTFAIL autolearn=no version=3.3.2 Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 13 Aug 2013 18:08:16 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MRH00J00EAOBK00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Tue, 13 Aug 2013 21:08:13 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MRH00IVTEDNP6G0@a-mtaout22.012.net.il>; Tue, 13 Aug 2013 21:08:11 +0300 (IDT) Date: Tue, 13 Aug 2013 18:08:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] Unbuffer stdout and stderr on windows In-reply-to: <20130812211105.GA11128@adacore.com> To: Joel Brobecker Cc: palves@redhat.com, gdb-patches@sourceware.org, yao@codesourcery.com Reply-to: Eli Zaretskii Message-id: <8361v9piop.fsf@gnu.org> 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> X-SW-Source: 2013-08/txt/msg00356.txt.bz2 > 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 think this problem is only relevant to the test suite, where a program tries to interpret the output and trips on extraneous characters. Let's not make the solution so much wider than the problem. With Yao's patch, you now have this in a Cygwin terminal; can we leave all the other types alone, please?