Make sure terminal settings are restored before exiting

  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(+)
  

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