[binutils-gdb] Avoid GDB SIGTTOU on catch exec + set follow-exec-mode new (PR 23368)

[sergiodj+buildbot at sergiodj dot net]

*** TEST RESULTS FOR COMMIT 35ed81d4f45855b98ea0c517b396662c3ae2a8c5 ***

Author: Simon Marchi <simon.marchi@polymtl.ca>
Branch: master
Commit: 35ed81d4f45855b98ea0c517b396662c3ae2a8c5

Avoid GDB SIGTTOU on catch exec + set follow-exec-mode new (PR 23368)

Here's a summary of PR 23368:

  #include <unistd.h>
  int main (void)
  {
    char *exec_args[] = { "/bin/ls", NULL };
    execve (exec_args[0], exec_args, NULL);
  }

$ gdb -nx t -ex "catch exec" -ex "set follow-exec-mode new" -ex run
...
[1]  + 13146 suspended (tty output)  gdb -q -nx t -ex "catch exec" -ex "set follow-exec-mode new" -ex run
$

Here's what happens: when the inferior execs with "follow-exec-mode
new", we first "mourn" it before creating the new one.  This ends up
calling inflow_inferior_exit, which sets the per-inferior terminal state
to "is_ours":

  inf->terminal_state = target_terminal_state::is_ours;

At this point, the inferior's terminal_state is is_ours, while the
"reality", tracked by gdb_tty_state, is is_inferior (GDB doesn't own the
terminal).

Later, we continue processing the exec inferior event and decide we want
to stop (because of the "catch exec") and call target_terminal::ours to
make sure we own the terminal.  However, we don't actually go to the
target backend to change the settings, because the core thinks that no
inferior owns the terminal (inf->terminal_state is
target_terminal_state::is_ours, as checked in
target_terminal_is_ours_kind, for both inferiors).  When something in
readline tries to mess with the terminal settings, it generates a
SIGTTOU.

This patch fixes this by tranferring the state of the terminal from the
old inferior to the new inferior.

gdb/ChangeLog:

	PR gdb/23368
	* infrun.c (follow_exec): In the follow_exec_mode_new case,
	transfer terminal state from old new new inferior.
	* terminal.h (swap_terminal_info): New function.
	* inflow.c (swap_terminal_info): New function.