Message ID | 1438053504-21507-1-git-send-email-patrick@parcs.ath.cx |
---|---|
State | New, archived |
Headers |
Received: (qmail 108168 invoked by alias); 28 Jul 2015 03:18:39 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 108105 invoked by uid 89); 28 Jul 2015 03:18:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL, BAYES_20, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-qg0-f46.google.com Received: from mail-qg0-f46.google.com (HELO mail-qg0-f46.google.com) (209.85.192.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 28 Jul 2015 03:18:33 +0000 Received: by qgeu79 with SMTP id u79so66769888qge.1 for <gdb-patches@sourceware.org>; Mon, 27 Jul 2015 20:18:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=88rcc94vvCbrUNw2YZLXe74qN15YsRWa6c1eHcKFJuA=; b=Z+pM6MsuG1I7CaDlP15YEdmZfBUGQb6fIBw1wNMnxK1G1b0lg4yyII9sXC5SgqjiPN qT454q1UJP5kMZHjZPhpeSpwWEXsizMFvQfoKmAF2JplZVqO294uFwZJPRSYfCZxZyDr 4JQnfvkSVb6Sz5k2km+B0y+FpTmsqPUEeNTWXsRfutY8t6LwLHLaU7KxT/vZuBa4i0Yh x431k38tZgoUrP9Vf+akhOG1RAzGffrxf931U0G6GTa3EbiEV6sx9bataJqefCq2gCN9 v9WS96dxPcikw3CzmSI6udeIJ1jEZAEKQ/m+4ShLXH/gBQBMzWIvLNiplKJNmFKa4sG8 jn5Q== X-Gm-Message-State: ALoCoQk3x6lWkRdiNXc2IvkLhO9dfAj/KEbezSSP5wm+9Nmr8dBJWFjfEvX8ho0yqrcak8MEGPMC X-Received: by 10.140.218.5 with SMTP id o5mr48695581qhb.13.1438053510926; Mon, 27 Jul 2015 20:18:30 -0700 (PDT) Received: from localhost.localdomain (ool-4353acd8.dyn.optonline.net. [67.83.172.216]) by smtp.gmail.com with ESMTPSA id 70sm10402424qhe.12.2015.07.27.20.18.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Jul 2015 20:18:30 -0700 (PDT) From: Patrick Palka <patrick@parcs.ath.cx> To: gdb-patches@sourceware.org Cc: Patrick Palka <patrick@parcs.ath.cx> Subject: [PATCH] Make sure terminal settings are restored before exiting Date: Mon, 27 Jul 2015 23:18:24 -0400 Message-Id: <1438053504-21507-1-git-send-email-patrick@parcs.ath.cx> |
Commit Message
Patrick Palka
July 28, 2015, 3:18 a.m. UTC
When exiting GDB -- whether it's via the "quit" command, via a SIGTERM, or otherwise -- we should leave the terminal in the state we acquired it. To that end, we have to undo any modifications that may have been made by the TUI (ncurses) or by the CLI (readline). [ Note that we already take a snapshot of the original tty state and save it to inflow.c:initial_gdb_ttystate. Using this variable we can define a new function restore_initial_gdb_ttystate and use it here. We can replace the call to rl_deprep_terminal with such a function, though it wouldn't hurt to have both around either. Is this a good idea? As far as testing goes, I am having trouble figuring out how to retrieve the pid of the GDB subprocess in order to kill it via SIGTERM with the subshell/stty approach used in batch-preserve-term-settings.exp. Seems non-trivial. Any ideas? ] gdb/ChangeLog: * top.c (quit_force): Undo any modifications that may have been made the terminal by calling target_terminal_ours, then tui_disable, then rl_deprep_terminal. --- gdb/top.c | 9 +++++++++ 1 file changed, 9 insertions(+)
Comments
On 07/28/2015 04:18 AM, Patrick Palka wrote: > When exiting GDB -- whether it's via the "quit" command, via a SIGTERM, > or otherwise -- we should leave the terminal in the state we acquired > it. To that end, we have to undo any modifications that may have been > made by the TUI (ncurses) or by the CLI (readline). > > [ Note that we already take a snapshot of the original tty state and save > it to inflow.c:initial_gdb_ttystate. Using this variable we can > define a new function restore_initial_gdb_ttystate and use it here. > We can replace the call to rl_deprep_terminal with such a function, > though it wouldn't hurt to have both around either. Is this a good > idea? > > As far as testing goes, I am having trouble figuring out how to > retrieve the pid of the GDB subprocess in order to kill it via SIGTERM > with the subshell/stty approach used in > batch-preserve-term-settings.exp. Seems non-trivial. Any ideas? ] A few ideas: #0 - We're starting it under a shell we control, so make use of that. Start gdb in the background "gdb &" and follow it with "echo $!" to get the pid, followed by "fg". Starting the background might be tricky, so alternatively start it as usual and then send a C-z to background it, then "echo $!". #1 - Run "shell ps" in gdb and extract the PID from the first column that has a line that matches *gdb*. #2 - Do like gdb.server/server-kill.c, and the test's program store the parent's process id in a global variable with getppid(). You'll need to disable "set startup-with-shell", so that the process's direct parent is GDB. Read the global variable from gdb. #3 - add a "maint print pid" command ... #0 seems preferred. #1 is hacky, but ... i've seen worse. #2 only works with native testing. #3 could be the most reliable... Thanks, Pedro Alves
On Tue, Jul 28, 2015 at 8:09 PM, Pedro Alves <palves@redhat.com> wrote: > On 07/28/2015 04:18 AM, Patrick Palka wrote: >> When exiting GDB -- whether it's via the "quit" command, via a SIGTERM, >> or otherwise -- we should leave the terminal in the state we acquired >> it. To that end, we have to undo any modifications that may have been >> made by the TUI (ncurses) or by the CLI (readline). >> >> [ Note that we already take a snapshot of the original tty state and save >> it to inflow.c:initial_gdb_ttystate. Using this variable we can >> define a new function restore_initial_gdb_ttystate and use it here. >> We can replace the call to rl_deprep_terminal with such a function, >> though it wouldn't hurt to have both around either. Is this a good >> idea? >> >> As far as testing goes, I am having trouble figuring out how to >> retrieve the pid of the GDB subprocess in order to kill it via SIGTERM >> with the subshell/stty approach used in >> batch-preserve-term-settings.exp. Seems non-trivial. Any ideas? ] > > A few ideas: > > #0 - We're starting it under a shell we control, so make use of that. > Start gdb in the background "gdb &" and follow it with "echo $!" to get > the pid, followed by "fg". Starting the background might be tricky, > so alternatively start it as usual and then send a C-z to background it, > then "echo $!". > > #1 - Run "shell ps" in gdb and extract the PID from the first column that has > a line that matches *gdb*. > > #2 - Do like gdb.server/server-kill.c, and the test's program store the parent's > process id in a global variable with getppid(). You'll need to disable > "set startup-with-shell", so that the process's direct parent is GDB. > Read the global variable from gdb. > > #3 - add a "maint print pid" command ... > > #0 seems preferred. > #1 is hacky, but ... i've seen worse. > #2 only works with native testing. > #3 could be the most reliable... Nice list. The #0 approach does not work for me. When I suspend GDB with ^Z, the shell variable $! remains empty. It looks like you have to start the process in the background to populate the $! variable, and starting GDB in the background does not work too well. Just very recently I discovered the $PPID environment variable, a standardized (thus hopefully portable) variable that should contain the pid of the parent process. With it we can do "shell echo $PPID" to print the gdb pid and then capture the output of this command with expect. I'll try this approach.
On 07/29/2015 12:37 PM, Patrick Palka wrote: > Just very recently I discovered the $PPID environment variable, a > standardized (thus hopefully portable) variable that should contain > the pid of the parent process. With it we can do "shell echo $PPID" > to print the gdb pid and then capture the output of this command with > expect. I'll try this approach. Good idea, sounds good. Thanks, Pedro Alves
diff --git a/gdb/top.c b/gdb/top.c index 1e30b1c..55f82ae 100644 --- a/gdb/top.c +++ b/gdb/top.c @@ -66,6 +66,7 @@ #include "cli-out.h" #include "tracepoint.h" #include "inf-loop.h" +#include "tui/tui.h" extern void initialize_all_files (void); @@ -1494,6 +1495,14 @@ quit_force (char *args, int from_tty) int exit_code = 0; struct qt_args qt; + /* Make sure that the terminal is left in the state we acquired it. */ + target_terminal_ours (); +#if defined(TUI) + tui_disable (); +#endif + if (async_command_editing_p) + rl_deprep_terminal (); + /* An optional expression may be used to cause gdb to terminate with the value of that expression. */ if (args)