Remove excess calls to gdb_flush

Message ID 20190307060601.GB26408@adacore.com
State New, archived
Headers

Commit Message

Joel Brobecker March 7, 2019, 6:06 a.m. UTC
  > >>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Pedro> On 02/19/2019 08:54 PM, Tom Tromey wrote:
> >> 
> >> my belief being that gdb's standard output
> >> streams are line buffered (by inheriting the behavior from stdio)
> 
> Pedro> That's only true if gdb is connected to a pty.  If gdb is started with
> Pedro> a pipe or regular file for stdout/stderr instead, then it won't be.  I
> Pedro> guess we could fix that with a setvbuf call at startup though.
> 
> I'll take a look.

I think the scenario being discussed here is slightly different
from what the diff below is for, but I thought I'd mention it,
just in case. At AdaCore, we have the following local change:
  

Patch

--- a/gdb/main.c
+++ b/gdb/main.c
@@ -527,6 +527,17 @@  captured_main_1 (struct captured_main_args *context)
     error (_("fatal error: libbfd ABI mismatch"));

 #ifdef __MINGW32__
+  /* On Windows hosts, when built using MinGW, we have some problems
+     with the terminal when running the debugger either under a cygwin
+     environment, or when connected to a GUI: When the debugger prints
+     an error, the actual printing on screen of the error message is
+     delayed and only finally printed after the next GDB prompt.
+     We avoid this issue by turning off buffering of stdout and stderr.  */
+  setvbuf (stdout, NULL, _IONBF, 0);
+  setvbuf (stderr, NULL, _IONBF, 0);
+#endif
+
+#ifdef __MINGW32__
   /* On Windows, argv[0] is not necessarily set to absolute form when
      GDB is found along PATH, without which relocation doesn't work.  */
   gdb_program_name = windows_get_absolute_argv0 (argv[0]);