Re: [PATCH] Make sure terminal settings are restored before exiting

[Patrick Palka <patrick at parcs dot ath dot cx>]

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.