From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id C66FD3858025 for ; Tue, 19 Apr 2022 16:12:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C66FD3858025 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-639-tVkljYPGMj-BNf1aafpggg-1; Tue, 19 Apr 2022 12:12:19 -0400 X-MC-Unique: tVkljYPGMj-BNf1aafpggg-1 Received: by mail-wm1-f69.google.com with SMTP id v62-20020a1cac41000000b0038cfe6edf3fso1550856wme.5 for ; Tue, 19 Apr 2022 09:12:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=eKPESQriAFgOgr2DzxUc05M4bpVdEx3ldGEWsbTLy+o=; b=M24c+iyDafjMB8KU1WPAUF+6/65cW2bGLjP2Z7ursywPZs5K0MR13Z7lQO1iBE9cdM LccogIodWlJgPyn5MpYzbBztO8CShp1nBsFatafJvU7KhNGEXkLs9gBxrDlSk6rO0N5y W2z8EeARXkLBImC7C8w/zrV4zLNQHFaSJph3B94/D5qk5eeYnVpdGZiN8nqxZ+KSLG/W 2qsi+GG5JEtTztS2k13tuQ252E615eT6REZrrXrHGuejbLUZShQS7WSuFzbY6HgD9I5F MAmu/CBqvSVSqM5ZpiXaTJGV7kR2xNtRP9SwjC8qF2k/jqVrlkqBx/7mxZKn9iR5rjHI h2iQ== X-Gm-Message-State: AOAM5321VxQrZCU30wG3muRgAtfasR1ge00rO3YfmatCaZmmCa4YB5Vf R1ZitWoxKhghXvxgH/75Y+NpyvMcuAV4nPzeWTYnRcTrJUpMaU4fREdNazfdGKfpxA9VEaKvcuw XSvO8EjUSc2ylqcr8DJ1akFZDf4eYiBJVxfq7fOJrlZ/DVAmUkAm8TJbBeAGHXu62gW4KLJxCMA == X-Received: by 2002:a05:6000:38b:b0:20a:923a:3aea with SMTP id u11-20020a056000038b00b0020a923a3aeamr8691780wrf.294.1650384737473; Tue, 19 Apr 2022 09:12:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwB6zma3V0hiqlqy7ri+QZl3P17gY9ItJ5Y9GefET3zWYKbHmvFls+DuaMRe03qumObeK+8Hw== X-Received: by 2002:a05:6000:38b:b0:20a:923a:3aea with SMTP id u11-20020a056000038b00b0020a923a3aeamr8691757wrf.294.1650384737079; Tue, 19 Apr 2022 09:12:17 -0700 (PDT) Received: from localhost (host81-136-113-48.range81-136.btcentralplus.com. [81.136.113.48]) by smtp.gmail.com with ESMTPSA id o13-20020a05600c4fcd00b00392951086efsm7405697wmq.34.2022.04.19.09.12.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Apr 2022 09:12:16 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Eli Zaretskii , Joel Brobecker , pedro@palves.net Subject: Re: GDB 12.0.90 available for testing In-Reply-To: References: <87pmm096dc.fsf@redhat.com> <83zgl44w1m.fsf@gnu.org> <1379565857.1750775.1648990951974@mail.yahoo.com> <1113857996.1779276.1648999598328@mail.yahoo.com> <83czhyfa8i.fsf@gnu.org> <83wng1b161.fsf@gnu.org> <83tuaz6e3x.fsf@gnu.org> Date: Tue, 19 Apr 2022 17:12:15 +0100 Message-ID: <874k2prr1c.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 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: Tue, 19 Apr 2022 16:12:22 -0000 Hi Eli, Joel, Sorry for the slow reply, I've been off for the last week, so I'm only just catching up with my GDB emails. How does the patch below look? This moves the setbuf call into a new function, and includes the comment from gdb_readline_no_editing_callback. Thanks, Andrew --- commit 3ee791edccae840e11b9ebe70e5547dfbec04e00 Author: Andrew Burgess Date: Tue Apr 19 17:00:04 2022 +0100 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 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. diff --git a/gdb/event-top.c b/gdb/event-top.c index b628f0397cb..a55338d78a2 100644 --- a/gdb/event-top.c +++ b/gdb/event-top.c @@ -818,19 +818,6 @@ gdb_readline_no_editing_callback (gdb_client_data client_data) 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 diff --git a/gdb/top.c b/gdb/top.c index 1cfffbeee7e..263a2ce8f43 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);