Re: GDB 12.0.90 available for testing

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 03 Apr 2022 18:38:21 +0300
> From: Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>
> 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 <ssbssa@yahoo.de>
> > Cc: Andrew Burgess <aburgess@redhat.com>, Eli Zaretskii <eliz@gnu.org>, 
> > 	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>, 
> > 	"pedro@palves.net" <pedro@palves.net>
> > 
> >  Am Sonntag, 3. April 2022, 16:02:51 MESZ hat Joel Brobecker <brobecker@adacore.com> 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);