From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 2B3BC3858C50 for ; Thu, 7 Apr 2022 11:09:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B3BC3858C50 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46964) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncQ0d-0000Jb-5B; Thu, 07 Apr 2022 07:09:03 -0400 Received: from [87.69.77.57] (port=3871 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 1ncQ0c-0000tg-J2; Thu, 07 Apr 2022 07:09:02 -0400 Date: Thu, 07 Apr 2022 14:09:10 +0300 Message-Id: <83wng1b161.fsf@gnu.org> From: Eli Zaretskii To: aburgess@redhat.com Cc: ssbssa@yahoo.de, pedro@palves.net, gdb-patches@sourceware.org, brobecker@adacore.com In-Reply-To: <83czhyfa8i.fsf@gnu.org> (message from Eli Zaretskii via Gdb-patches on Sun, 03 Apr 2022 18:38:21 +0300) Subject: Re: GDB 12.0.90 available for testing References: <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> <83zgl44w1m.fsf@gnu.org> <1379565857.1750775.1648990951974@mail.yahoo.com> <1113857996.1779276.1648999598328@mail.yahoo.com> <83czhyfa8i.fsf@gnu.org> X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Thu, 07 Apr 2022 11:09:05 -0000 > Date: Sun, 03 Apr 2022 18:38:21 +0300 > From: Eli Zaretskii via Gdb-patches > Cc: pedro@palves.net, aburgess@redhat.com, gdb-patches@sourceware.org, > brobecker@adacore.com > > > Date: Sun, 3 Apr 2022 15:26:38 +0000 (UTC) > > From: Hannes Domani > > Cc: Andrew Burgess , Eli Zaretskii , > > "gdb-patches@sourceware.org" , > > "pedro@palves.net" > > > > Am Sonntag, 3. April 2022, 16:02:51 MESZ hat Joel Brobecker Folgendes geschrieben: > > > > But I found out now that on Windows the combination of > > setbuf/WaitForMultipleObjects doesn't work correctly with fgetc. > > WaitForMultipleObjects is called by console_select_thread in ser-mingw.c, > > so the following is a minimal reproducer of the problem (but for some reason > > I always see character 'f' instead of 'g'): > > In general, to switch the console to unbuffered reads, shouldn't we > call SetConsoleMode to force raw input from the console? > > > I don't really see a solution beside some "#ifdef _WIN32" code to fix this. > > That was my conclusion as well. Can we please finalize the fix for this? The following patch, which is a variation on the patch that Andrew sent, works for me. If there are no objections, I'd like to install it on both branches (with a suitable log message describing the misbehavior on MS-Windows). Thanks. --- gdb/event-top.c~0 2022-03-20 06:59:56.000000000 +0200 +++ gdb/event-top.c 2022-04-01 14:06:22.164500000 +0300 @@ -821,19 +821,6 @@ gdb_readline_no_editing_callback (gdb_cl FILE *stream = ui->instream != nullptr ? ui->instream : ui->stdin_stream; gdb_assert (stream != nullptr); - /* Unbuffer the input stream, so that, later on, the calls to fgetc - fetch only one char at the time from the stream. The fgetc's will - get up to the first newline, but there may be more chars in the - stream after '\n'. If we buffer the input and fgetc drains the - stream, getting stuff beyond the newline as well, a select, done - afterwards will not trigger. - - This unbuffering was, at one point, not applied if the input stream - was a tty, however, the buffering can cause problems, even for a tty, - in some cases. Please ensure that any changes in this area run the MI - tests with the FORCE_SEPARATE_MI_TTY=1 flag being passed. */ - setbuf (stream, NULL); - /* We still need the while loop here, even though it would seem obvious to invoke gdb_readline_no_editing_callback at every character entered. If not using the readline library, the --- gdb/top.c~0 2022-04-07 14:01:19.479625000 +0300 +++ gdb/top.c 2022-04-07 13:56:54.995250000 +0300 @@ -286,6 +286,15 @@ ui::ui (FILE *instream_, FILE *outstream { buffer_init (&line_buffer); +#ifdef __MINGW32__ + /* With MS-Windows runtime, making stdin unbuffered when it's + connected to the terminal causes it to misbehave. */ + if (!ISATTY (instream_)) + setbuf (instream_, NULL); +#else + setbuf (instream_, NULL); +#endif + if (ui_list == NULL) ui_list = this; else @@ -415,6 +424,8 @@ read_command_file (FILE *stream) { struct ui *ui = current_ui; + setbuf (stream, nullptr); + scoped_restore save_instream = make_scoped_restore (&ui->instream, stream);