* [PATCH 2/3] Don't force interpreter sync mode in execute_gdb_command.
2012-05-25 9:56 Fix PR14135 Yao Qi
@ 2012-05-25 9:56 ` Yao Qi
2013-07-30 19:55 ` Tom Tromey
2012-05-25 9:56 ` [PATCH 3/3] Match output in async mode Yao Qi
` (2 subsequent siblings)
3 siblings, 1 reply; 14+ messages in thread
From: Yao Qi @ 2012-05-25 9:56 UTC (permalink / raw)
To: gdb-patches
This patch is to fix the internal error reported in PR14135
FAIL: gdb.python/py-finish-breakpoint.exp: check MyFinishBreakpoint hit (GDB
internal error)
This internal error is caused by GDB fetches inferior event recursively
(fetch_inferior_event -> bpstat_check_breakpoint_conditions -> gdbpy_should_stop
-> execute_gdb_command -> fetch_inferior_event), and you can see backtrace
in details in comment#2 in PR14135. It is caused by forcing interpreter to
sync mode by this patch
Flip the interpreter to synchronously wait for commands finishing, in command lists and similars
http://sourceware.org/ml/gdb-patches/2011-09/msg00037.html
This patch is correct, but I think we don't have to force interpreter into sync
in execute_gdb_command. execute_gdb_command is called from two paths,
1. python_command. When we type 'python gdb.execute ("foo")", it goes in path,
since interpreter_async has been set to zero in this path, we don't have to
set it again in execute_gdb_command.
2. gdbpy_should_stop. When we write python script to do "gdb.execute ("foo")"
in gdb.Breakpoint::Stop () method, async mode of interpreter doesn't matter.
Because the commands people can use here are restricted to not "alter execute
state of inferior", so it should be to issue second command when the
first one is not finished.
Noe that this patch doesn't fix all the fails in PR14135.
gdb:
2012-05-24 Yao Qi <yao@codesourcery.com>
PR 14135.
* python/python.c (execute_gdb_command): Don't force the interpreter
to sync mode.
---
gdb/python/python.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/gdb/python/python.c b/gdb/python/python.c
index 19eb7b5..2d2ed3a 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -441,9 +441,6 @@ execute_gdb_command (PyObject *self, PyObject *args, PyObject *kw)
char *copy = xstrdup (arg);
struct cleanup *cleanup = make_cleanup (xfree, copy);
- make_cleanup_restore_integer (&interpreter_async);
- interpreter_async = 0;
-
prevent_dont_repeat ();
if (to_string)
result = execute_command_to_string (copy, from_tty);
--
1.7.0.4
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH 3/3] Match output in async mode.
2012-05-25 9:56 Fix PR14135 Yao Qi
2012-05-25 9:56 ` [PATCH 2/3] Don't force interpreter sync mode in execute_gdb_command Yao Qi
@ 2012-05-25 9:56 ` Yao Qi
2013-07-30 20:06 ` Tom Tromey
2012-05-25 9:56 ` [PATCH 1/3] New test case for PR12929 Yao Qi
2012-07-17 2:51 ` Fix PR14135 Yao Qi
3 siblings, 1 reply; 14+ messages in thread
From: Yao Qi @ 2012-05-25 9:56 UTC (permalink / raw)
To: gdb-patches
This patch is to match the program's output when in async mode. It is
hard to match output in a unique way to handle both sync mode and
async mode, so I have to handle them separately.
The reason I choose send_gdb/gdb_expect, instead of gdb_test_multiple,
is gdb_test_multiple matches ""\r\n$gdb_prompt $", and return false.
However, "(gdb) " may appear in somewhere in the output, and trigger
fail for test.
With this patch, I run py-finish-breakpoint.exp 40 times in both
sync mode and async mode, no fail show up.
gdb/testsuite:
2012-05-25 Yao Qi <yao@codesourcery.com>
Fix PR 14135.
* gdb.python/py-finish-breakpoint.exp: Match output in async
mode.
---
gdb/testsuite/gdb.python/py-finish-breakpoint.exp | 69 ++++++++++++++++++--
1 files changed, 62 insertions(+), 7 deletions(-)
diff --git a/gdb/testsuite/gdb.python/py-finish-breakpoint.exp b/gdb/testsuite/gdb.python/py-finish-breakpoint.exp
index c601e85..4ab15e7 100644
--- a/gdb/testsuite/gdb.python/py-finish-breakpoint.exp
+++ b/gdb/testsuite/gdb.python/py-finish-breakpoint.exp
@@ -65,6 +65,22 @@ if ![runto_main] then {
}
gdb_test_no_output "set confirm off" "disable confirmation"
+
+set async "unknown"
+global gdb_prompt
+send_gdb "show target-async\n"
+gdb_expect {
+ -re ".*Controlling the inferior in asynchronous mode is on.*$gdb_prompt $" {
+ set async 1
+ }
+ -re ".*$gdb_prompt $" {
+ set async 0
+ }
+ timeout {
+ set async 0
+ }
+}
+
gdb_test "source $python_file" "Python script imported.*" \
"import python scripts"
gdb_breakpoint "increase_1"
@@ -169,9 +185,22 @@ gdb_test "break ${cond_line} if test_1(i,8)" "Breakpoint .* at .*" \
"set a conditional BP"
gdb_test "python TestBreakpoint()" "TestBreakpoint init" \
"set FinishBP in a breakpoint condition"
-gdb_test "continue" \
- "\"FinishBreakpoint\" cannot be set on a dummy frame.*" \
- "don't allow FinishBreakpoint on dummy frames"
+
+set test "don't allow FinishBreakpoint on dummy frames"
+
+if {$async} {
+ send_gdb "continue\n"
+ gdb_expect {
+ -re "\"FinishBreakpoint\" cannot be set on a dummy frame\\..* Condition Break\. " {
+ pass $test
+ }
+ }
+} else {
+ gdb_test "continue" \
+ "\"FinishBreakpoint\" cannot be set on a dummy frame.*" \
+ $test
+}
+
gdb_test "print i" "8" "check stopped location"
#
@@ -194,12 +223,38 @@ gdb_test "break ${cond_line} if test(i,8)" \
"Breakpoint .* at .*" "set conditional BP"
gdb_test "python TestBreakpoint()" "TestBreakpoint init" "set BP in condition"
-gdb_test "continue" \
- "test don't stop: 1.*test don't stop: 2.*test stop.*Error in testing breakpoint condition.*The program being debugged stopped while in a function called from GDB.*" \
- "stop in condition function"
+set test "stop in condition function"
+
+if {$async} {
+
+ send_gdb "continue\n"
+ gdb_expect {
+ -re "continue.*Continuing\\..*test don't stop: 1.*test don't stop: 2.*test stop.*Error in testing breakpoint condition.*The program being debugged stopped while in a function called from GDB.*Breakpoint " {
+ pass $test
+ }
+
+ timeout { fail "$test (timeout)" }
+ }
+} else {
+ gdb_test "continue" \
+ "test don't stop: 1.*test don't stop: 2.*test stop.*Error in testing breakpoint condition.*The program being debugged stopped while in a function called from GDB.*" \
+ $test
+}
gdb_test "continue" "Continuing.*" "finish condition evaluation"
-gdb_test "continue" "Breakpoint.*" "stop at conditional breakpoint"
+
+set test "stop at conditional breakpoint"
+if {$async} {
+ send_gdb "continue\n"
+ gdb_expect {
+ -re "continue.*Breakpoint.* Condition Break\\. " {
+ pass $test
+ }
+ }
+} else {
+ gdb_test "continue" "Breakpoint.*" $test
+}
+
gdb_test "print i" "8" "check stopped location"
#
--
1.7.0.4
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 3/3] Match output in async mode.
2012-05-25 9:56 ` [PATCH 3/3] Match output in async mode Yao Qi
@ 2013-07-30 20:06 ` Tom Tromey
2013-07-31 7:45 ` Yao Qi
0 siblings, 1 reply; 14+ messages in thread
From: Tom Tromey @ 2013-07-30 20:06 UTC (permalink / raw)
To: Yao Qi; +Cc: gdb-patches
>>>>> "Yao" == Yao Qi <yao@codesourcery.com> writes:
Yao> This patch is to match the program's output when in async mode. It is
Yao> hard to match output in a unique way to handle both sync mode and
Yao> async mode, so I have to handle them separately.
Yao> The reason I choose send_gdb/gdb_expect, instead of gdb_test_multiple,
Yao> is gdb_test_multiple matches ""\r\n$gdb_prompt $", and return false.
Yao> However, "(gdb) " may appear in somewhere in the output, and trigger
Yao> fail for test.
I don't understand the need for this patch.
It seems to me that everything in this test case is async.
The setting of "target-async" therefore should not matter -- with
target-async enabled (either explicitly in today's gdb, or implicitly
after my patch series), sync commands should work exactly as they would
in the "async disabled" gdb.
Tom
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 3/3] Match output in async mode.
2013-07-30 20:06 ` Tom Tromey
@ 2013-07-31 7:45 ` Yao Qi
0 siblings, 0 replies; 14+ messages in thread
From: Yao Qi @ 2013-07-31 7:45 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
On 07/31/2013 04:06 AM, Tom Tromey wrote:
> The setting of "target-async" therefore should not matter -- with
> target-async enabled (either explicitly in today's gdb, or implicitly
> after my patch series), sync commands should work exactly as they would
> in the "async disabled" gdb.
I agree with you, Tom. Sync commands should behave in "sync" even in
async enabled gdb. I withdraw this patch and path 2/3.
--
Yao (é½å°§)
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 1/3] New test case for PR12929.
2012-05-25 9:56 Fix PR14135 Yao Qi
2012-05-25 9:56 ` [PATCH 2/3] Don't force interpreter sync mode in execute_gdb_command Yao Qi
2012-05-25 9:56 ` [PATCH 3/3] Match output in async mode Yao Qi
@ 2012-05-25 9:56 ` Yao Qi
2013-07-30 19:49 ` Tom Tromey
2012-07-17 2:51 ` Fix PR14135 Yao Qi
3 siblings, 1 reply; 14+ messages in thread
From: Yao Qi @ 2012-05-25 9:56 UTC (permalink / raw)
To: gdb-patches
PR12929 was fixed by this patch,
Flip the interpreter to synchronously wait for commands finishing, in command lists and similars
http://sourceware.org/ml/gdb-patches/2011-09/msg00037.html
but we don't have a test case for it. My following patch will affect this
part, so I add a test case to make sure my patch doesn't break anything.
gdb/testsuite:
* gdb.python/py-sync-interp.c: New.
* gdb.python/py-sync-interp.exp: New.
---
gdb/testsuite/gdb.python/py-sync-interp.c | 47 +++++++++++++++++++
gdb/testsuite/gdb.python/py-sync-interp.exp | 67 +++++++++++++++++++++++++++
2 files changed, 114 insertions(+), 0 deletions(-)
create mode 100644 gdb/testsuite/gdb.python/py-sync-interp.c
create mode 100644 gdb/testsuite/gdb.python/py-sync-interp.exp
diff --git a/gdb/testsuite/gdb.python/py-sync-interp.c b/gdb/testsuite/gdb.python/py-sync-interp.c
new file mode 100644
index 0000000..716f43d
--- /dev/null
+++ b/gdb/testsuite/gdb.python/py-sync-interp.c
@@ -0,0 +1,47 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2012 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/>. */
+
+/* This program is intended to be started outside of gdb, and then
+ attached to by gdb. It loops for a while, but not forever. */
+
+#include <unistd.h>
+
+static void
+foo1 (void)
+{
+ sleep (100);
+}
+
+static void
+foo2 (void)
+{
+ foo1 ();
+}
+
+static void
+foo3 (void)
+{
+ foo2 ();
+}
+
+int
+main (void)
+{
+
+ foo3 ();
+ return 0;
+}
diff --git a/gdb/testsuite/gdb.python/py-sync-interp.exp b/gdb/testsuite/gdb.python/py-sync-interp.exp
new file mode 100644
index 0000000..a094b96
--- /dev/null
+++ b/gdb/testsuite/gdb.python/py-sync-interp.exp
@@ -0,0 +1,67 @@
+# Copyright (C) 2012 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/>.
+
+# This file is part of the GDB testsuite. It tests the mechanism
+# for defining the prompt in Python.
+
+# This test case is copied from PR14135.
+# http://sourceware.org/bugzilla/show_bug.cgi?id=14135
+
+set testfile "py-sync-interp"
+set srcfile ${testfile}.c
+set binfile ${objdir}/${subdir}/${testfile}
+
+# We need to use TCL's exec to get the pid.
+if [is_remote target] then {
+ return 0
+}
+
+load_lib gdb-python.exp
+
+# Start with a fresh gdb.
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+
+# Skip all tests if Python scripting is not enabled.
+if { [skip_python_tests] } { continue }
+gdb_exit
+
+if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile}] } {
+ return -1
+}
+
+# Start the program running and then wait for a bit, to be sure
+# that it can be attached to.
+set testpid [eval exec $binfile &]
+exec sleep 2
+if { [istarget "*-*-cygwin*"] } {
+ # testpid is the Cygwin PID, GDB uses the Windows PID, which might be
+ # different due to the way fork/exec works.
+ set testpid [ exec ps -e | gawk "{ if (\$1 == $testpid) print \$4; }" ]
+}
+
+# Test command 'where' is executed when command 'attach' is done, otherwise
+# function 'sleep' may not show up in backtrace.
+
+gdb_test_sequence "python gdb.execute(\"attach $testpid\"); gdb.execute(\"where\")" \
+ "attach and where" {
+ "\[\r\n\]#.* in sleep \\(\\) "
+ "\[\r\n\]#.* in foo1 \\(\\) at "
+ "\[\r\n\]#.* in foo2 \\(\\) at "
+ "\[\r\n\]#.* in foo3 \\(\\) at "
+ "\[\r\n\]#.* in main \\(\\) at "
+}
--
1.7.0.4
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 1/3] New test case for PR12929.
2012-05-25 9:56 ` [PATCH 1/3] New test case for PR12929 Yao Qi
@ 2013-07-30 19:49 ` Tom Tromey
2013-07-30 20:11 ` Tom Tromey
2013-07-31 7:53 ` Yao Qi
0 siblings, 2 replies; 14+ messages in thread
From: Tom Tromey @ 2013-07-30 19:49 UTC (permalink / raw)
To: Yao Qi; +Cc: gdb-patches
>>>>> "Yao" == Yao Qi <yao@codesourcery.com> writes:
Yao> * gdb.python/py-sync-interp.c: New.
Yao> * gdb.python/py-sync-interp.exp: New.
Yao> +# This test case is copied from PR14135.
Yao> +# http://sourceware.org/bugzilla/show_bug.cgi?id=14135
Yao> +
Yao> +set testfile "py-sync-interp"
Yao> +set srcfile ${testfile}.c
Yao> +set binfile ${objdir}/${subdir}/${testfile}
standard_testfile
Yao> +# Test command 'where' is executed when command 'attach' is done, otherwise
Yao> +# function 'sleep' may not show up in backtrace.
Yao> +
Yao> +gdb_test_sequence "python gdb.execute(\"attach $testpid\"); gdb.execute(\"where\")" \
Yao> + "attach and where" {
Yao> + "\[\r\n\]#.* in sleep \\(\\) "
Yao> + "\[\r\n\]#.* in foo1 \\(\\) at "
Yao> + "\[\r\n\]#.* in foo2 \\(\\) at "
Yao> + "\[\r\n\]#.* in foo3 \\(\\) at "
Yao> + "\[\r\n\]#.* in main \\(\\) at "
Yao> +}
I applied this patch to my branch, to see what would happen. On my
system (x86-64 Fedora 18, with glibc debuginfo installed), I see this
backtrace in the log:
python gdb.execute("attach 11985"); gdb.execute("where")
0x0000003e422bb4e0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
#0 0x0000003e422bb4e0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
#1 0x0000003e422bb3a1 in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:137
#2 0x00000000004005da in foo1 () at ../../../archer/gdb/testsuite/gdb.python/py-sync-interp.c:26
#3 0x00000000004005e5 in foo2 () at ../../../archer/gdb/testsuite/gdb.python/py-sync-interp.c:32
#4 0x00000000004005f0 in foo3 () at ../../../archer/gdb/testsuite/gdb.python/py-sync-interp.c:38
#5 0x00000000004005fb in main () at ../../../archer/gdb/testsuite/gdb.python/py-sync-interp.c:45
This yielded a FAIL:
FAIL: gdb.python/py-sync-interp.exp: attach and where (pattern 1)
Tom
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 1/3] New test case for PR12929.
2013-07-30 19:49 ` Tom Tromey
@ 2013-07-30 20:11 ` Tom Tromey
2013-07-31 7:53 ` Yao Qi
1 sibling, 0 replies; 14+ messages in thread
From: Tom Tromey @ 2013-07-30 20:11 UTC (permalink / raw)
To: Yao Qi; +Cc: gdb-patches
Tom> This yielded a FAIL:
Tom> FAIL: gdb.python/py-sync-interp.exp: attach and where (pattern 1)
...I meant to say, I don't think the FAIL is warranted.
It seems like a buglet in the test case.
Tom
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/3] New test case for PR12929.
2013-07-30 19:49 ` Tom Tromey
2013-07-30 20:11 ` Tom Tromey
@ 2013-07-31 7:53 ` Yao Qi
2013-07-31 15:19 ` Tom Tromey
1 sibling, 1 reply; 14+ messages in thread
From: Yao Qi @ 2013-07-31 7:53 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
On 07/31/2013 03:49 AM, Tom Tromey wrote:
> I applied this patch to my branch, to see what would happen. On my
> system (x86-64 Fedora 18, with glibc debuginfo installed), I see this
> backtrace in the log:
>
> python gdb.execute("attach 11985"); gdb.execute("where")
> 0x0000003e422bb4e0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
> 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
> #0 0x0000003e422bb4e0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
> #1 0x0000003e422bb3a1 in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:137
> #2 0x00000000004005da in foo1 () at ../../../archer/gdb/testsuite/gdb.python/py-sync-interp.c:26
> #3 0x00000000004005e5 in foo2 () at ../../../archer/gdb/testsuite/gdb.python/py-sync-interp.c:32
> #4 0x00000000004005f0 in foo3 () at ../../../archer/gdb/testsuite/gdb.python/py-sync-interp.c:38
> #5 0x00000000004005fb in main () at ../../../archer/gdb/testsuite/gdb.python/py-sync-interp.c:45
>
>
> This yielded a FAIL:
>
> FAIL: gdb.python/py-sync-interp.exp: attach and where (pattern 1)
Tom,
The pattern is updated to ".*sleep \\(.*\\)" to match the output.
--
Yao (é½å°§)
gdb/testsuite:
* gdb.python/py-sync-interp.c: New.
* gdb.python/py-sync-interp.exp: New.
---
gdb/testsuite/gdb.python/py-sync-interp.c | 46 +++++++++++++++++++++
gdb/testsuite/gdb.python/py-sync-interp.exp | 59 +++++++++++++++++++++++++++
2 files changed, 105 insertions(+), 0 deletions(-)
create mode 100644 gdb/testsuite/gdb.python/py-sync-interp.c
create mode 100644 gdb/testsuite/gdb.python/py-sync-interp.exp
diff --git a/gdb/testsuite/gdb.python/py-sync-interp.c b/gdb/testsuite/gdb.python/py-sync-interp.c
new file mode 100644
index 0000000..5ae770a
--- /dev/null
+++ b/gdb/testsuite/gdb.python/py-sync-interp.c
@@ -0,0 +1,46 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2013 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/>. */
+
+/* This program is intended to be started outside of gdb, and then
+ attached to by gdb. It loops for a while, but not forever. */
+
+#include <unistd.h>
+
+static void
+foo1 (void)
+{
+ sleep (100);
+}
+
+static void
+foo2 (void)
+{
+ foo1 ();
+}
+
+static void
+foo3 (void)
+{
+ foo2 ();
+}
+
+int
+main (void)
+{
+ foo3 ();
+ return 0;
+}
diff --git a/gdb/testsuite/gdb.python/py-sync-interp.exp b/gdb/testsuite/gdb.python/py-sync-interp.exp
new file mode 100644
index 0000000..cfa75db
--- /dev/null
+++ b/gdb/testsuite/gdb.python/py-sync-interp.exp
@@ -0,0 +1,59 @@
+# Copyright (C) 2013 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/>.
+
+# This file is part of the GDB testsuite.
+
+# This test case is copied from PR12929.
+# http://sourceware.org/bugzilla/show_bug.cgi?id=12929
+
+standard_testfile
+
+# We need to use TCL's exec to get the pid.
+if [is_remote target] then {
+ return 0
+}
+
+load_lib gdb-python.exp
+
+# Start with a fresh gdb.
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+
+# Skip all tests if Python scripting is not enabled.
+if { [skip_python_tests] } { continue }
+gdb_exit
+
+if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile}] } {
+ return -1
+}
+
+# Start the program running and then wait for a bit, to be sure
+# that it can be attached to.
+set testpid [eval exec $binfile &]
+exec sleep 2
+if { [istarget "*-*-cygwin*"] } {
+ # testpid is the Cygwin PID, GDB uses the Windows PID, which might be
+ # different due to the way fork/exec works.
+ set testpid [ exec ps -e | gawk "{ if (\$1 == $testpid) print \$4; }" ]
+}
+
+# Test command 'where' is executed when command 'attach' is done, otherwise
+# function 'sleep' may not show up in backtrace.
+
+gdb_test "python gdb.execute(\"attach $testpid\"); gdb.execute(\"where\")" \
+ "in .*sleep \\(.*\\) .* in foo1 \\(\\) at .* in foo2 \\(\\) at .*" \
+ "attach and where"
--
1.7.7.6
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Fix PR14135
2012-05-25 9:56 Fix PR14135 Yao Qi
` (2 preceding siblings ...)
2012-05-25 9:56 ` [PATCH 1/3] New test case for PR12929 Yao Qi
@ 2012-07-17 2:51 ` Yao Qi
3 siblings, 0 replies; 14+ messages in thread
From: Yao Qi @ 2012-07-17 2:51 UTC (permalink / raw)
To: gdb-patches
On Friday, May 25, 2012 05:56:03 PM Yao Qi wrote:
> This patch series is to fix PR14135, some python test fails in
> async mode. Patch 1/3 is a new test case for PR12929, which
> will be used to prove my later changes are correct.
>
> Patch 2/3 and 3/3 are to fix PR14135.
>
> Regression tested on x86_64-linux {native,gdbserver} x {sync, async}.
Forget to ping this patch. :)
Ping. http://sourceware.org/ml/gdb-patches/2012-05/msg00963.html
--
Yao (齐尧)
^ permalink raw reply [flat|nested] 14+ messages in thread