aboutsummaryrefslogtreecommitdiff
path: root/gdb/top.c
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2022-04-24 08:39:19 -0700
committerJoel Brobecker <brobecker@adacore.com>2022-04-24 08:39:19 -0700
commitac16b09d7e5fd0013ffa27e4d0531c0af12a529a (patch)
tree2279a478129e5f341dca19210a0eeb39620a5578 /gdb/top.c
parent69be4d89e30e0a6f0476ede2e34748330cd72445 (diff)
downloadgdb-ac16b09d7e5fd0013ffa27e4d0531c0af12a529a.zip
gdb-ac16b09d7e5fd0013ffa27e4d0531c0af12a529a.tar.gz
gdb-ac16b09d7e5fd0013ffa27e4d0531c0af12a529a.tar.bz2
gdb: move setbuf calls out of gdb_readline_no_editing_callback
After this commit: commit d08cbc5d3203118da5583296e49273cf82378042 Date: Wed Dec 22 12:57:44 2021 +0000 gdb: unbuffer all input streams when not using readline Issues were reported with some MS-Windows hosts, see the thread starting here: https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html Filed in bugzilla as: PR mi/29002 The problem seems to be that calling setbuf on terminal file handles is not always acceptable, see this mail for more details: https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html This commit does two things, first moving the setbuf calls out of gdb_readline_no_editing_callback so that we don't end up calling setbuf so often. Then, for MS-Windows hosts, we don't call setbuf for terminals, this appears to resolve the issues that have been reported. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29002
Diffstat (limited to 'gdb/top.c')
-rw-r--r--gdb/top.c39
1 files changed, 39 insertions, 0 deletions
diff --git a/gdb/top.c b/gdb/top.c
index 73cb389..86c9971 100644
--- a/gdb/top.c
+++ b/gdb/top.c
@@ -257,6 +257,41 @@ void (*deprecated_context_hook) (int id);
/* The highest UI number ever assigned. */
static int highest_ui_num;
+/* Unbuffer STREAM. This is a wrapper around setbuf(STREAM, nullptr)
+ which applies some special rules for MS-Windows hosts. */
+
+static void
+unbuffer_stream (FILE *stream)
+{
+ /* Unbuffer the input stream so that in gdb_readline_no_editing_callback,
+ the calls to fgetc fetch only one char at the time from STREAM.
+
+ This is important because gdb_readline_no_editing_callback will read
+ from STREAM up to the first '\n' character, after this GDB returns to
+ the event loop and relies on a select on STREAM indicating that more
+ input is pending.
+
+ If STREAM is buffered then the fgetc calls may have moved all the
+ pending input from the kernel into a local buffer, after which the
+ select will not indicate that more input is pending, and input after
+ the first '\n' will not be processed immediately.
+
+ Please ensure that any changes in this area run the MI tests with the
+ FORCE_SEPARATE_MI_TTY=1 flag being passed. */
+
+#ifdef __MINGW32__
+ /* With MS-Windows runtime, making stdin unbuffered when it's
+ connected to the terminal causes it to misbehave. */
+ if (!ISATTY (stream))
+ setbuf (stream, nullptr);
+#else
+ /* On GNU/Linux the issues described above can impact GDB even when
+ dealing with input from a terminal. For now we unbuffer the input
+ stream for everyone except MS-Windows. */
+ setbuf (stream, nullptr);
+#endif
+}
+
/* See top.h. */
ui::ui (FILE *instream_, FILE *outstream_, FILE *errstream_)
@@ -283,6 +318,8 @@ ui::ui (FILE *instream_, FILE *outstream_, FILE *errstream_)
{
buffer_init (&line_buffer);
+ unbuffer_stream (instream_);
+
if (ui_list == NULL)
ui_list = this;
else
@@ -412,6 +449,8 @@ read_command_file (FILE *stream)
{
struct ui *ui = current_ui;
+ unbuffer_stream (stream);
+
scoped_restore save_instream
= make_scoped_restore (&ui->instream, stream);