This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug breakpoints/23368] gdb goes to into background when hitting exec catchpoint with follow-exec-mode new
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 23 Oct 2018 21:02:03 +0000
- Subject: [Bug breakpoints/23368] gdb goes to into background when hitting exec catchpoint with follow-exec-mode new
- Auto-submitted: auto-generated
- References: <bug-23368-4717@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=23368
--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <simark@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=35ed81d4f45855b98ea0c517b396662c3ae2a8c5
commit 35ed81d4f45855b98ea0c517b396662c3ae2a8c5
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date: Tue Oct 23 17:00:33 2018 -0400
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.
--
You are receiving this mail because:
You are on the CC list for the bug.