[pushed+7.8] Re: [PATCH] Fix "attach" command vs user input race [Re: Regression for attach from stdin [Re: [pushed] Re: [PATCH v6 0/2] enable target-async by default]]
Commit Message
On 07/09/2014 05:37 PM, Doug Evans wrote:
> spurious change
Fixed.
> I like this a lot better. Thanks.
> The patch is ok with me, modulo removing the spurious change.
Here's what I pushed to both master and gdb-7.8-branch.
Thanks.
-------------
From 1fe2833b6dd03602ba86aa334e81466ea9abe66a Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Wed, 9 Jul 2014 17:52:58 +0100
Subject: [PATCH] Fix "attach" command vs user input race
On async targets, a synchronous attach is done like this:
#1 - target_attach is called (PTRACE_ATTACH is issued)
#2 - a continuation is installed
#3 - we go back to the event loop
#4 - target reports stop (SIGSTOP), event loop wakes up, and
attach continuation is called
#5 - among other things, the continuation calls
target_terminal_inferior, which removes stdin from the event
loop
Note that in #3, GDB is still processing user input. If the user is
fast enough, e.g., with something like:
echo -e "attach PID\nset xxx=1" | gdb
... then the "set" command is processed before the attach completes.
We get worse behavior even, if input is a tty and therefore
readline/editing is enabled, with e.g.,:
(gdb) attach PID\nset xxx=1
we then crash readline/gdb, with:
Attaching to program: attach-wait-input, process 14537
readline: readline_callback_read_char() called with no handler!
Aborted
$
Fix this by calling target_terminal_inferior before #3 above.
The test covers both scenarios by running with editing/readline forced
to both on and off.
gdb/
2014-07-09 Pedro Alves <palves@redhat.com>
* infcmd.c (attach_command_post_wait): Don't call
target_terminal_inferior here.
(attach_command): Call it here instead.
gdb/testsuite/
2014-07-09 Pedro Alves <palves@redhat.com>
* gdb.base/attach-wait-input.exp: New file.
* gdb.base/attach-wait-input.c: New file.
---
gdb/ChangeLog | 6 ++
gdb/testsuite/ChangeLog | 5 ++
gdb/infcmd.c | 19 ++++-
gdb/testsuite/gdb.base/attach-wait-input.c | 40 +++++++++
gdb/testsuite/gdb.base/attach-wait-input.exp | 119 +++++++++++++++++++++++++++
5 files changed, 186 insertions(+), 3 deletions(-)
create mode 100644 gdb/testsuite/gdb.base/attach-wait-input.c
create mode 100644 gdb/testsuite/gdb.base/attach-wait-input.exp
Comments
On Wed, Jul 9, 2014 at 10:09 AM, Pedro Alves <palves@redhat.com> wrote:
> On 07/09/2014 05:37 PM, Doug Evans wrote:
>
>> spurious change
>
> Fixed.
>
>> I like this a lot better. Thanks.
>> The patch is ok with me, modulo removing the spurious change.
>
> Here's what I pushed to both master and gdb-7.8-branch.
>
> Thanks.
>
> -------------
> From 1fe2833b6dd03602ba86aa334e81466ea9abe66a Mon Sep 17 00:00:00 2001
> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 9 Jul 2014 17:52:58 +0100
> Subject: [PATCH] Fix "attach" command vs user input race
>
> On async targets, a synchronous attach is done like this:
>
> #1 - target_attach is called (PTRACE_ATTACH is issued)
> #2 - a continuation is installed
> #3 - we go back to the event loop
> #4 - target reports stop (SIGSTOP), event loop wakes up, and
> attach continuation is called
> #5 - among other things, the continuation calls
> target_terminal_inferior, which removes stdin from the event
> loop
>
> Note that in #3, GDB is still processing user input. If the user is
> fast enough, e.g., with something like:
>
> echo -e "attach PID\nset xxx=1" | gdb
>
> ... then the "set" command is processed before the attach completes.
>
> We get worse behavior even, if input is a tty and therefore
> readline/editing is enabled, with e.g.,:
>
> (gdb) attach PID\nset xxx=1
>
> we then crash readline/gdb, with:
>
> Attaching to program: attach-wait-input, process 14537
> readline: readline_callback_read_char() called with no handler!
> Aborted
> $
>
> Fix this by calling target_terminal_inferior before #3 above.
>
> The test covers both scenarios by running with editing/readline forced
> to both on and off.
>
> gdb/
> 2014-07-09 Pedro Alves <palves@redhat.com>
>
> * infcmd.c (attach_command_post_wait): Don't call
> target_terminal_inferior here.
> (attach_command): Call it here instead.
>
> gdb/testsuite/
> 2014-07-09 Pedro Alves <palves@redhat.com>
>
> * gdb.base/attach-wait-input.exp: New file.
> * gdb.base/attach-wait-input.c: New file.
Hi.
Is this TODO still needed after this patch?
infcmd.c:
/*
* TODO:
* Should save/restore the tty state since it might be that the
* program to be debugged was started on this tty and it wants
* the tty in some state other than what we want. If it's running
* on another terminal or without a terminal, then saving and
* restoring the tty state is a harmless no-op.
* This only needs to be done if we are attaching to a process.
*/
On Tue, Jul 29, 2014 at 2:48 PM, Doug Evans <dje@google.com> wrote:
> On Wed, Jul 9, 2014 at 10:09 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 07/09/2014 05:37 PM, Doug Evans wrote:
>>
>>> spurious change
>>
>> Fixed.
>>
>>> I like this a lot better. Thanks.
>>> The patch is ok with me, modulo removing the spurious change.
>>
>> Here's what I pushed to both master and gdb-7.8-branch.
>>
>> Thanks.
>>
>> -------------
>> From 1fe2833b6dd03602ba86aa334e81466ea9abe66a Mon Sep 17 00:00:00 2001
>> From: Pedro Alves <palves@redhat.com>
>> Date: Wed, 9 Jul 2014 17:52:58 +0100
>> Subject: [PATCH] Fix "attach" command vs user input race
>>
>> On async targets, a synchronous attach is done like this:
>>
>> #1 - target_attach is called (PTRACE_ATTACH is issued)
>> #2 - a continuation is installed
>> #3 - we go back to the event loop
>> #4 - target reports stop (SIGSTOP), event loop wakes up, and
>> attach continuation is called
>> #5 - among other things, the continuation calls
>> target_terminal_inferior, which removes stdin from the event
>> loop
>>
>> Note that in #3, GDB is still processing user input. If the user is
>> fast enough, e.g., with something like:
>>
>> echo -e "attach PID\nset xxx=1" | gdb
>>
>> ... then the "set" command is processed before the attach completes.
>>
>> We get worse behavior even, if input is a tty and therefore
>> readline/editing is enabled, with e.g.,:
>>
>> (gdb) attach PID\nset xxx=1
>>
>> we then crash readline/gdb, with:
>>
>> Attaching to program: attach-wait-input, process 14537
>> readline: readline_callback_read_char() called with no handler!
>> Aborted
>> $
>>
>> Fix this by calling target_terminal_inferior before #3 above.
>>
>> The test covers both scenarios by running with editing/readline forced
>> to both on and off.
>>
>> gdb/
>> 2014-07-09 Pedro Alves <palves@redhat.com>
>>
>> * infcmd.c (attach_command_post_wait): Don't call
>> target_terminal_inferior here.
>> (attach_command): Call it here instead.
>>
>> gdb/testsuite/
>> 2014-07-09 Pedro Alves <palves@redhat.com>
>>
>> * gdb.base/attach-wait-input.exp: New file.
>> * gdb.base/attach-wait-input.c: New file.
>
> Hi.
>
> Is this TODO still needed after this patch?
>
> infcmd.c:
>
> /*
> * TODO:
> * Should save/restore the tty state since it might be that the
> * program to be debugged was started on this tty and it wants
> * the tty in some state other than what we want. If it's running
> * on another terminal or without a terminal, then saving and
> * restoring the tty state is a harmless no-op.
> * This only needs to be done if we are attaching to a process.
> */
A related issue (or the same one if one prefers):
post_create_inferior does this:
/* Be sure we own the terminal in case write operations are performed. */
target_terminal_ours ();
but post_create_inferior is called *after* target_post_attach
in attach_command_post_wait:
/* Take any necessary post-attaching actions for this platform. */
target_post_attach (ptid_get_pid (inferior_ptid));
post_create_inferior (¤t_target, from_tty);
What if target_post_attach does some writes?
Seems like it can, e.g., some of the ptrace checking stuff may print a warning.
Plus attach_command_post_wait calls some other stuff before
post_create_inferior that could cause some writes to the terminal.
Question: Is there a specific terminal state that needs to be in
effect when attach_command_post_wait returns?
Or can we just call target_terminal_ours at its start?
[and leave it to other code to switch back to target_terminal_inferior
as needed - e.g. proceed calls resume which will call
target_terminal_inferior]
On 07/29/2014 10:48 PM, Doug Evans wrote:
> On Wed, Jul 9, 2014 at 10:09 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 07/09/2014 05:37 PM, Doug Evans wrote:
>>
>>> spurious change
>>
>> Fixed.
>>
>>> I like this a lot better. Thanks.
>>> The patch is ok with me, modulo removing the spurious change.
>>
>> Here's what I pushed to both master and gdb-7.8-branch.
>>
>> Thanks.
>>
>> -------------
>> From 1fe2833b6dd03602ba86aa334e81466ea9abe66a Mon Sep 17 00:00:00 2001
>> From: Pedro Alves <palves@redhat.com>
>> Date: Wed, 9 Jul 2014 17:52:58 +0100
>> Subject: [PATCH] Fix "attach" command vs user input race
>>
>> On async targets, a synchronous attach is done like this:
>>
>> #1 - target_attach is called (PTRACE_ATTACH is issued)
>> #2 - a continuation is installed
>> #3 - we go back to the event loop
>> #4 - target reports stop (SIGSTOP), event loop wakes up, and
>> attach continuation is called
>> #5 - among other things, the continuation calls
>> target_terminal_inferior, which removes stdin from the event
>> loop
>>
>> Note that in #3, GDB is still processing user input. If the user is
>> fast enough, e.g., with something like:
>>
>> echo -e "attach PID\nset xxx=1" | gdb
>>
>> ... then the "set" command is processed before the attach completes.
>>
>> We get worse behavior even, if input is a tty and therefore
>> readline/editing is enabled, with e.g.,:
>>
>> (gdb) attach PID\nset xxx=1
>>
>> we then crash readline/gdb, with:
>>
>> Attaching to program: attach-wait-input, process 14537
>> readline: readline_callback_read_char() called with no handler!
>> Aborted
>> $
>>
>> Fix this by calling target_terminal_inferior before #3 above.
>>
>> The test covers both scenarios by running with editing/readline forced
>> to both on and off.
>>
>> gdb/
>> 2014-07-09 Pedro Alves <palves@redhat.com>
>>
>> * infcmd.c (attach_command_post_wait): Don't call
>> target_terminal_inferior here.
>> (attach_command): Call it here instead.
>>
>> gdb/testsuite/
>> 2014-07-09 Pedro Alves <palves@redhat.com>
>>
>> * gdb.base/attach-wait-input.exp: New file.
>> * gdb.base/attach-wait-input.c: New file.
>
> Hi.
>
> Is this TODO still needed after this patch?
>
> infcmd.c:
>
> /*
> * TODO:
> * Should save/restore the tty state since it might be that the
> * program to be debugged was started on this tty and it wants
> * the tty in some state other than what we want. If it's running
> * on another terminal or without a terminal, then saving and
> * restoring the tty state is a harmless no-op.
> * This only needs to be done if we are attaching to a process.
> */
>
As usual, git blame/log is your friend...
That's been in place for over 20 years. In bd5635a1 (1991), we see:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/*
* TODO:
* Should save/restore the tty state since it might be that the
* program to be debugged was started on this tty and it wants
* the tty in some state other than what we want. If it's running
* on another terminal or without a terminal, then saving and
* restoring the tty state is a harmless no-op.
* This only needs to be done if we are attaching to a process.
*/
/*
* attach_command --
* takes a program started up outside of gdb and ``attaches'' to it.
* This stops it cold in its tracks and allows us to start tracing it.
* For this to work, we must be able to send the process a
* signal and we must have the same effective uid as the program.
*/
void
attach_command (args, from_tty)
char *args;
int from_tty;
{
target_attach (args, from_tty);
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So clearly the TODO has been stale for a long while.
We've been saving/restoring the tty state way before
my patch.
Thanks,
Pedro Alves
On 07/29/2014 11:03 PM, Doug Evans wrote:
> A related issue (or the same one if one prefers):
>
> post_create_inferior does this:
>
> /* Be sure we own the terminal in case write operations are performed. */
> target_terminal_ours ();
Yeah.
As I mentioned before, when I wrote a test that sends a ctrl-c right
after "attach", which triggered the issue mentioned in the new
comment,
- installs a SIGINT handler that forwards SIGINT to the inferior.
Otherwise a Ctrl-C pressed just while waiting for the initial
stop would end up as a spurious Quit.
it tripped on a set of other races.
This call was one of them. We should actually be calling
target_terminal_ours_for_output, not target_terminal_ours, so
that stdin/ctrl-c is still redirected to the inferior. As is,
IIRC, if a ctrl-c arrives after than target_terminal_ours and before
the next target_terminal_inferior, we end up in the prompt, with
a Quit, but with the target still running.
I gave up fixing those at the time, as they're orthogonal to
sync/async.
>
> but post_create_inferior is called *after* target_post_attach
> in attach_command_post_wait:
>
> /* Take any necessary post-attaching actions for this platform. */
> target_post_attach (ptid_get_pid (inferior_ptid));
>
> post_create_inferior (¤t_target, from_tty);
>
> What if target_post_attach does some writes?
Something should call target_terminal_ours_for_output before.
> Seems like it can, e.g., some of the ptrace checking stuff may print a warning.
> Plus attach_command_post_wait calls some other stuff before
> post_create_inferior that could cause some writes to the terminal.
>
> Question: Is there a specific terminal state that needs to be in
> effect when attach_command_post_wait returns?
> Or can we just call target_terminal_ours at its start?
I think we can.
> [and leave it to other code to switch back to target_terminal_inferior
> as needed - e.g. proceed calls resume which will call
> target_terminal_inferior]
Even with that, it'll still be possible to have a ctrl-c pressed after
to_attach is called, and before target_terminal_inferior is called
(and therefore set_sigint_trap is called, which sets up ctrl-c
forwarding).
When I last looked at this, it seemed to be that ideally, we should
only have a single SIGINT handler, which just records that a ctrl-c was
pressed, and then the event loop decides whether a ctrl-c is a Quit or
whether it should be forwarded to the inferior, depending on whether the
target is running on the foreground, or not.
On Wed, Jul 30, 2014 at 5:05 AM, Pedro Alves <palves@redhat.com> wrote:
>>> [...]
>>> gdb/
>>> 2014-07-09 Pedro Alves <palves@redhat.com>
>>>
>>> * infcmd.c (attach_command_post_wait): Don't call
>>> target_terminal_inferior here.
>>> (attach_command): Call it here instead.
>>>
>>> gdb/testsuite/
>>> 2014-07-09 Pedro Alves <palves@redhat.com>
>>>
>>> * gdb.base/attach-wait-input.exp: New file.
>>> * gdb.base/attach-wait-input.c: New file.
>>
>> Hi.
>>
>> Is this TODO still needed after this patch?
>>
>> infcmd.c:
>>
>> /*
>> * TODO:
>> * Should save/restore the tty state since it might be that the
>> * program to be debugged was started on this tty and it wants
>> * the tty in some state other than what we want. If it's running
>> * on another terminal or without a terminal, then saving and
>> * restoring the tty state is a harmless no-op.
>> * This only needs to be done if we are attaching to a process.
>> */
>>
>
> As usual, git blame/log is your friend...
>
> That's been in place for over 20 years. In bd5635a1 (1991), we see:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /*
> * TODO:
> * Should save/restore the tty state since it might be that the
> * program to be debugged was started on this tty and it wants
> * the tty in some state other than what we want. If it's running
> * on another terminal or without a terminal, then saving and
> * restoring the tty state is a harmless no-op.
> * This only needs to be done if we are attaching to a process.
> */
>
> /*
> * attach_command --
> * takes a program started up outside of gdb and ``attaches'' to it.
> * This stops it cold in its tracks and allows us to start tracing it.
> * For this to work, we must be able to send the process a
> * signal and we must have the same effective uid as the program.
> */
> void
> attach_command (args, from_tty)
> char *args;
> int from_tty;
> {
> target_attach (args, from_tty);
> }
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> So clearly the TODO has been stale for a long while.
23 years? Zoinks! :)
> We've been saving/restoring the tty state way before
> my patch.
>
> Thanks,
> Pedro Alves
>
It wasn't clear to me whether the comment was (trying to) refer to
something more specific for the task at hand. Just being too literal
I guess.
Thanks.
On Wed, 09 Jul 2014 19:09:29 +0200, Pedro Alves wrote:
> Here's what I pushed to both master and gdb-7.8-branch.
https://sourceware.org/bugzilla/show_bug.cgi?id=17347
sleep 1h&p=$!;sleep 0.1;gdb -batch sleep $p -ex r
PASS:
[2] 22970
0x0000003fdf8bc780 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
/usr/bin/sleep: missing operand
Try '/usr/bin/sleep --help' for more information.
[Inferior 1 (process 23030) exited with code 01]
[2]+ Killed sleep 1h
FAIL:
[2] Killed sleep 1h
[3]+ Stopped ./gdb/gdb -batch sleep $! -ex r
7180e04a36d812bbea2c280f2db33a7e8ce6b07b is the first bad commit
commit 7180e04a36d812bbea2c280f2db33a7e8ce6b07b
Author: Pedro Alves <palves@redhat.com>
Date: Wed Jul 9 15:59:02 2014 +0100
Fix "attach" command vs user input race
private Red Hat reference: https://bugzilla.redhat.com/show_bug.cgi?id=1136704
@@ -1,3 +1,9 @@
+2014-07-09 Pedro Alves <palves@redhat.com>
+
+ * infcmd.c (attach_command_post_wait): Don't call
+ target_terminal_inferior here.
+ (attach_command): Call it here instead.
+
2014-07-07 Pedro Alves <palves@redhat.com>
PR gdb/17096
@@ -1,3 +1,8 @@
+2014-07-09 Pedro Alves <palves@redhat.com>
+
+ * gdb.base/attach-wait-input.exp: New file.
+ * gdb.base/attach-wait-input.c: New file.
+
2014-06-23 Siva Chandra Reddy <sivachandra@google.com>
* gdb.python/py-xmethods.exp: Use "progspace" instead of the
@@ -2381,9 +2381,6 @@ attach_command_post_wait (char *args, int from_tty, int async_exec)
post_create_inferior (¤t_target, from_tty);
- /* Install inferior's terminal modes. */
- target_terminal_inferior ();
-
if (async_exec)
{
/* The user requested an `attach&', so be sure to leave threads
@@ -2499,6 +2496,22 @@ attach_command (char *args, int from_tty)
based on what modes we are starting it with. */
target_terminal_init ();
+ /* Install inferior's terminal modes. This may look like a no-op,
+ as we've just saved them above, however, this does more than
+ restore terminal settings:
+
+ - installs a SIGINT handler that forwards SIGINT to the inferior.
+ Otherwise a Ctrl-C pressed just while waiting for the initial
+ stop would end up as a spurious Quit.
+
+ - removes stdin from the event loop, which we need if attaching
+ in the foreground, otherwise on targets that report an initial
+ stop on attach (which are most) we'd process input/commands
+ while we're in the event loop waiting for that stop. That is,
+ before the attach continuation runs and the command is really
+ finished. */
+ target_terminal_inferior ();
+
/* Set up execution context to know that we should return from
wait_for_inferior as soon as the target reports a stop. */
init_wait_for_inferior ();
new file mode 100644
@@ -0,0 +1,40 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2014 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+#include <sys/types.h>
+#include <unistd.h>
+
+volatile int should_exit = 0;
+int mypid;
+
+static void
+setup_done (void)
+{
+}
+
+int
+main (void)
+{
+ unsigned int counter = 1;
+
+ mypid = getpid ();
+ setup_done ();
+
+ for (counter = 0; !should_exit && counter < 100; counter++)
+ sleep (1);
+ return 0;
+}
new file mode 100644
@@ -0,0 +1,119 @@
+# Copyright 2014 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+# Verify that GDB waits for the "attach" command to finish before
+# processing the following command.
+#
+# GDB used to have a race where on async targets, in the small window
+# between the attach request and the initial stop for the attach, GDB
+# was still processing user input.
+#
+# The issue was originally detected with:
+#
+# echo -e "attach PID\nset xxx=1" | gdb
+#
+# In that scenario, stdin is not a tty, which disables readline.
+# Explicitly turning off editing exercises the same code path, and is
+# simpler to do, so we test with both editing on and off.
+
+# The test uses the "attach" command.
+if [target_info exists use_gdb_stub] {
+ return
+}
+
+standard_testfile
+
+if {[build_executable "failed to build" $testfile $srcfile debug]} {
+ return -1
+}
+
+# Start the program running, and return its PID, ready for attaching.
+
+proc start_program {binfile} {
+ global gdb_prompt
+ global decimal
+
+ clean_restart $binfile
+
+ if ![runto setup_done] then {
+ fail "Can't run to setup_done"
+ return 0
+ }
+
+ # Get the PID of the test process.
+ set testpid ""
+ set test "get inferior process ID"
+ gdb_test_multiple "p mypid" $test {
+ -re " = ($decimal)\r\n$gdb_prompt $" {
+ set testpid $expect_out(1,string)
+ pass $test
+ }
+ }
+
+ gdb_test "detach" "Detaching from program: .*"
+
+ if {$testpid == ""} {
+ return
+ }
+
+ return $testpid
+}
+
+# Do test proper. EDITING indicates whether "set editing" is on or
+# off.
+
+proc test { editing } {
+ global gdb_prompt
+ global binfile
+ global decimal
+
+ with_test_prefix "editing $editing" {
+
+ set testpid [start_program $binfile]
+ if {$testpid == ""} {
+ return
+ }
+
+ # Enable/disable readline.
+ gdb_test_no_output "set editing $editing"
+
+ # Send both commands at once.
+ send_gdb "attach $testpid\nprint should_exit = 1\n"
+
+ # Use gdb_expect directly instead of gdb_test_multiple to
+ # avoid races with the double prompt.
+ set test "attach and print"
+ gdb_expect {
+ -re "Attaching to program.*process $testpid\r\n.*$gdb_prompt.*$decimal = 1\r\n$gdb_prompt $" {
+ pass "$test"
+ }
+ timeout {
+ fail "$test (timeout)"
+ }
+ }
+
+ # As we've used attach, on quit, we'll detach from the
+ # program. Explicitly kill it in case we failed above.
+ gdb_test "kill" \
+ "" \
+ "after attach, exit" \
+ "Kill the program being debugged.*y or n. $" \
+ "y"
+ }
+}
+
+foreach editing {"on" "off"} {
+ test $editing
+}