From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id G1EgFNwlR2IvXQAAWB0awg (envelope-from ) for ; Fri, 01 Apr 2022 12:18:36 -0400 Received: by simark.ca (Postfix, from userid 112) id 3EF051F1F4; Fri, 1 Apr 2022 12:18:36 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 9F1941E787 for ; Fri, 1 Apr 2022 12:18:35 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DEB553839400 for ; Fri, 1 Apr 2022 16:18:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DEB553839400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1648829914; bh=MbpQq72pTVRYdShk/bBN1Z5xhad5Kk0QvWwiXOQ/rwA=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=XUvuA9xMoPiF0jYaGMxRvPyJNu588o1E/x4wAErJ5Rvf34VqlLapjtXIYcFvt1O2x 2JGEPJ32JAM+RWrfTdHWZjVROkHHXZG8O/NpoQfyQP5pW621QyyPk6fpIvqRJY269w mv5IGbfWVXEMTuDWa9vwEscQKx2KNBqpi/vx1HBw= Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id E55FE3858D28 for ; Fri, 1 Apr 2022 16:18:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E55FE3858D28 Received: from [2001:470:142:3::e] (port=56800 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1naJyN-00012n-Rx; Fri, 01 Apr 2022 12:18:03 -0400 Received: from [87.69.77.57] (port=1576 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1naJyK-0004Ld-Dp; Fri, 01 Apr 2022 12:18:03 -0400 Date: Fri, 01 Apr 2022 19:18:13 +0300 Message-Id: <83zgl44w1m.fsf@gnu.org> To: Andrew Burgess In-Reply-To: <87pmm096dc.fsf@redhat.com> (message from Andrew Burgess on Fri, 01 Apr 2022 16:21:35 +0100) Subject: Re: GDB 12.0.90 available for testing References: <20220320055815.2A90FA4D6C@takamaka.home> <83sfr4a93r.fsf@gnu.org> <83pmm8a7gn.fsf@gnu.org> <83o81sa6nu.fsf@gnu.org> <83ilrzap07.fsf@gnu.org> <83mth67i8m.fsf@gnu.org> <72ad3448-0ff0-f36c-d1f3-cc194c0503b8@palves.net> <83ee2i72vl.fsf@gnu.org> <87sfqx864d.fsf@redhat.com> <83fsmx59wi.fsf@gnu.org> <83ee2h59m2.fsf@gnu.org> <87pmm096dc.fsf@redhat.com> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: brobecker@adacore.com, gdb-patches@sourceware.org, pedro@palves.net Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > From: Andrew Burgess > Cc: pedro@palves.net, gdb-patches@sourceware.org, brobecker@adacore.com > Date: Fri, 01 Apr 2022 16:21:35 +0100 > > >> So I guess there are problems with making the console input stream > >> unbuffered, at least on MS-Windows? > > > > Or maybe read_command_file shouldn't call setbuf for the same stream > > repeatedly, but only once? > > I think it must be the former, as far as I can tell with the patch I > posted we call setbuf just once on stdin (for your -i=mi case). The > read_command_file will only be called if you have gdbinit files to read > in. You could try adding the -nx and -nh options when starting GDB to > prevent any gdbinit files being read, but I'd be amazed if that makes a > difference. It indeed doesn't. > Sorry I can't offer more insight. So what would be the way forward? The patch below fixes the problem for me. But given that Joel says the problem doesn't happen in your MinGW builds, maybe we shouldn't install it, even for MinGW? Or condition it only by symbols available in mingw.org's MingW? --- gdb/top.c~1 2022-03-28 16:27:31.211375000 +0300 +++ gdb/top.c 2022-04-01 19:12:33.617625000 +0300 @@ -286,6 +286,9 @@ ui::ui (FILE *instream_, FILE *outstream { buffer_init (&line_buffer); + if (!ISATTY (instream_)) + setbuf (instream_, NULL); + if (ui_list == NULL) ui_list = this; else @@ -415,6 +418,8 @@ read_command_file (FILE *stream) { struct ui *ui = current_ui; + setbuf (stream, nullptr); + scoped_restore save_instream = make_scoped_restore (&ui->instream, stream);