This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]