GDB kills itself instead of interrupting inferior

When GDB is run with IO redirected to a pipe, the 'interrupt' command
causes it to kill its own process group instead of the inferior's.
The problem manifests itself in async mode, native debugging:

    $ cat | gdb <file>
    (gdb) set target-async on
    (gdb) run &
    (gdb) interrupt
    A debugging session is active.
    Inferior 1 [process 20584] will be killed.
    Quit anyway? (y or n) [answered Y; input not from terminal]

In this case, GDB tells that its stdin isn't a tty and doesn't save
the inferior's process group in
inflow.c:terminal_init_inferior_with_pgrp.  The 'interrupt' command
tries to 'kill' the inferior's process group in
`inf-ptrace.c:inf_ptrace_stop`, but since that wasn't saved in the
first place, GDB kills process group 0, meaning, its own process
group.

When GDB is used from a frontend, that means killing its own process
group including the frontend and possibly the X session.  This was
originally seen with SublimeGDB:
  https://github.com/quarnster/SublimeGDB/issues/29.

The patch makes GDB save the inferior pgid regardless of having a
terminal, as pgid is used not only to reset foreground process group,
but also to interrupt the inferior process.  It also adds a regression
test.  Luckily, we can emulate not having a terminal with "set
interactive-mode off", avoiding the need of special magic to spawn gdb
with a pipe.

Tested on x86_64 Fedora 17.

gdb/
2013-07-26  Cyril Nikolaev  <cyril@nichtverstehen.de>

	* inflow.c (terminal_init_inferior_with_pgrp): Save inferior
	process group regardless of having tty on stdin.

gdb/testsuite/
2013-07-26  Pedro Alves  <palves@redhat.com>

	* gdb.base/interrupt-noterm.c, gdb.base/interrupt-noterm.exp: New
	files.

0 files changed, 0 insertions, 0 deletions