From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23550 invoked by alias); 22 Aug 2016 21:51:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 23471 invoked by uid 89); 22 Aug 2016 21:51:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=Hx-languages-length:2639 X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 Aug 2016 21:51:17 +0000 Received: by simark.ca (Postfix, from userid 112) id 6C5E41E7C5; Mon, 22 Aug 2016 17:51:16 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 401781E192; Mon, 22 Aug 2016 17:51:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 22 Aug 2016 21:51:00 -0000 From: Simon Marchi To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH master+7.12] Fix PR20494 - User input stops being echoed in CLI In-Reply-To: <1471888116-17074-1-git-send-email-palves@redhat.com> References: <1471888116-17074-1-git-send-email-palves@redhat.com> Message-ID: <4259d32e531a408cf08eb25ec549e63f@simark.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.0 X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00221.txt.bz2 On 2016-08-22 13:48, Pedro Alves wrote: > This patch fixes a problem that problem triggers if you start an > inferior, e.g., with the "start" command, in a UI created with the > new-ui command, and then run a foreground execution command in the > main UI. Once the program stops for the latter command, typing in the > main UI no longer echoes back to the user. > > The problem revolves around this: > > - gdb_has_a_terminal computes its result lazily, on first call. > > that is what saves gdb's initial main UI terminal state (the UI > associated with stdin): > > our_terminal_info.ttystate = serial_get_tty_state > (stdin_serial); > > This is the state that target_terminal_ours() restores. > > - In this scenario, the gdb_has_a_terminal function happens to be > first ever called from within the target_terminal_init call in > startup_inferior: > > (top-gdb) bt > #0 gdb_has_a_terminal () at src/gdb/inflow.c:157 > #1 0x000000000079db22 in child_terminal_init_with_pgrp () at > src/gdb/inflow.c:217 > [...] > #4 0x000000000065bacb in target_terminal_init () at > src/gdb/target.c:456 > #5 0x00000000004676d2 in startup_inferior () at > src/gdb/fork-child.c:531 > [...] > #7 0x000000000046b168 in linux_nat_create_inferior () at > src/gdb/linux-nat.c:1112 > [...] > #9 0x00000000005f20c9 in start_command (args=0x0, from_tty=1) > at src/gdb/infcmd.c:657 > > If the command to start the inferior is issued on the main UI, then > readline will have deprepped the terminal when we reach the above, and > the problem doesn't appear. > > If however the command is issued on a non-main UI, then when we reach > that gdb_has_a_terminal call, the main UI's terminal state is still > set to whatever readline has sets it to in rl_prep_terminal, which > happens to have echo disabled. Later, when the following synchronous > execution command finishes, we'll call target_terminal_ours to restore > gdb's the main UI's terminal settings, and that restores the terminal > state with echo disabled... > > Conceptually, the fix is to move the gdb_has_a_terminal call earlier, > to someplace during GDB initialization, before readline/ncurses have > had a chance to change terminal settings. Turns out that > "set_initial_gdb_ttystate" is exactly such a place. > > I say conceptually, because the fix actually inlines the > gdb_has_a_terminal part that saves the terminal state in > set_initial_gdb_ttystate and then simplifies gdb_has_a_terminal, since > there's no point in making gdb_has_a_terminal do lazy computation. Well, it does fix the problem we observed, so +1!