From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 1141) id 0AE503858D33; Sun, 24 Apr 2022 15:44:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0AE503858D33 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Joel Brobecker To: gdb-cvs@sourceware.org Subject: [binutils-gdb/gdb-12-branch] gdb: move setbuf calls out of gdb_readline_no_editing_callback X-Act-Checkin: binutils-gdb X-Git-Author: Andrew Burgess X-Git-Refname: refs/heads/gdb-12-branch X-Git-Oldrev: 3ab22dba1b7ef469b743e5606731ebc1169fbafa X-Git-Newrev: e312dfbe9556d8e4557abe7fd3f1a4681e15da06 Message-Id: <20220424154418.0AE503858D33@sourceware.org> Date: Sun, 24 Apr 2022 15:44:18 +0000 (GMT) X-BeenThere: gdb-cvs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-cvs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2022 15:44:18 -0000 https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3De312dfbe9556= d8e4557abe7fd3f1a4681e15da06 commit e312dfbe9556d8e4557abe7fd3f1a4681e15da06 Author: Andrew Burgess Date: Sun Apr 24 08:39:19 2022 -0700 gdb: move setbuf calls out of gdb_readline_no_editing_callback =20 After this commit: =20 commit d08cbc5d3203118da5583296e49273cf82378042 Date: Wed Dec 22 12:57:44 2021 +0000 =20 gdb: unbuffer all input streams when not using readline =20 Issues were reported with some MS-Windows hosts, see the thread starting here: =20 https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html =20 Filed in bugzilla as: PR mi/29002 =20 The problem seems to be that calling setbuf on terminal file handles is not always acceptable, see this mail for more details: =20 https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html =20 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. =20 Then, for MS-Windows hosts, we don't call setbuf for terminals, this appears to resolve the issues that have been reported. =20 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29002 Diff: --- gdb/event-top.c | 13 ------------- gdb/top.c | 39 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 39 insertions(+), 13 deletions(-) diff --git a/gdb/event-top.c b/gdb/event-top.c index c1a95a4b748..e924d10fa02 100644 --- a/gdb/event-top.c +++ b/gdb/event-top.c @@ -821,19 +821,6 @@ gdb_readline_no_editing_callback (gdb_client_data clie= nt_data) FILE *stream =3D ui->instream !=3D nullptr ? ui->instream : ui->stdin_st= ream; gdb_assert (stream !=3D nullptr); =20 - /* 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=3D1 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 diff --git a/gdb/top.c b/gdb/top.c index 7831b4f96ca..3b39b7d1bfe 100644 --- a/gdb/top.c +++ b/gdb/top.c @@ -260,6 +260,41 @@ void (*deprecated_context_hook) (int id); /* The highest UI number ever assigned. */ static int highest_ui_num; =20 +/* 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=3D1 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. */ =20 ui::ui (FILE *instream_, FILE *outstream_, FILE *errstream_) @@ -286,6 +321,8 @@ ui::ui (FILE *instream_, FILE *outstream_, FILE *errstr= eam_) { buffer_init (&line_buffer); =20 + unbuffer_stream (instream_); + if (ui_list =3D=3D NULL) ui_list =3D this; else @@ -415,6 +452,8 @@ read_command_file (FILE *stream) { struct ui *ui =3D current_ui; =20 + unbuffer_stream (stream); + scoped_restore save_instream =3D make_scoped_restore (&ui->instream, stream);