skip "attach" tests when testing against stub-like targets (was: Re: [PATCH 5/5] Test attaching to a program that constantly spawns short-lived threads)
Commit Message
On 01/05/2015 07:01 PM, Breazeal, Don wrote:
> On 12/17/2014 4:02 PM, Pedro Alves wrote:
>
>> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
>> index 08087f2..83fa1d0 100644
>> --- a/gdb/testsuite/lib/gdb.exp
>> +++ b/gdb/testsuite/lib/gdb.exp
>> @@ -3413,12 +3413,36 @@ proc gdb_exit { } {
>> catch default_gdb_exit
>> }
>>
>> +# Return true if we can spawn a program on the target and attach to
>> +# it.
>> +
>> +proc can_spawn_for_attach { } {
>> + # We use TCL's exec to get the inferior's pid.
>> + if [is_remote target] then {
>> + return 0
>> + }
>> +
>> + # The "attach" command doesn't make sense when the target is
>> + # stub-like, where GDB finds the program already started on
>> + # initial connection.
>> + if {[target_info exists use_gdb_stub]} {
>> + return 0
>> + }
>> +
>> + # Assume yes.
>> + return 1
>> +}
>> +
> This solves the problem that I was working on here:
>
> https://sourceware.org/ml/gdb-patches/2014-12/msg00520.html
>
> When I call can_spawn_for_attach in the misbehaving attach tests I was
> working on, they no longer spawn processes for 'target remote' that they
> can't attach to. Thanks!
Great!
>
>> # Start a set of programs running and then wait for a bit, to be sure
>> # that they can be attached to. Return a list of the processes' PIDs.
>>
>> proc spawn_wait_for_attach { executable_list } {
>> set pid_list {}
>>
>> + if ![can_spawn_for_attach] {
>> + error "can't spawn for attach with this target/board"
>> + }
>
> Should this be calling "error", or should it call something like
> "untested" or "unsupported", since it isn't expected to work in these cases?
The idea is that all .exp files that use spawn_wait_for_attach
would have already checked can_spawn_for_attach early, and skipped the
tests if false. That makes is a test bug to see a call to
spawn_wait_for_attach if can_spawn_for_attach is false.
I should have really split those hunks out to a separate patch and
added calls to can_spawn_for_attach in all tests that are using
spawn_wait_for_attach already. Like below. WDYT?
(There are probably other attach tests that don't use
spawn_wait_for_attach that need the can_spawn_for_attach too.
We can do this incrementally.)
--------
From a7d938a9ca3762ea195a20b796772865a47283b6 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Wed, 7 Jan 2015 15:38:02 +0000
Subject: [PATCH] skip "attach" tests when testing against stub-like targets
We already skip "attach" tests if the target board is remote, in
dejagnu's sense, as we use TCL's exec to spawn the program on the
build machine. We should also skip these tests if testing with
"target remote" or other stub-like targets where "attach" doesn't make
sense.
Add a helper procedure that centralizes the checks a test that needs
to spawn a program for testing "attach" and make all test files that
use spawn_wait_for_attach check it.
gdb/testsuite/
2014-12-17 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (can_spawn_for_attach): New procedure.
(spawn_wait_for_attach): Error out if can_spawn_for_attach returns
false.
* gdb.base/attach.exp: Use can_spawn_for_attach instead of
checking whether the target board is remote.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Use can_spawn_for_attach before the
tests that need to attach, instead of checking whether the target
board is remote at the top of the file.
---
gdb/testsuite/gdb.base/attach.exp | 3 +--
gdb/testsuite/gdb.base/solib-overlap.exp | 3 +--
gdb/testsuite/gdb.multi/multi-attach.exp | 3 +--
gdb/testsuite/gdb.python/py-prompt.exp | 9 ++++-----
gdb/testsuite/gdb.python/py-sync-interp.exp | 3 +--
gdb/testsuite/gdb.server/ext-attach.exp | 3 +--
gdb/testsuite/lib/gdb.exp | 27 +++++++++++++++++++++++++++
7 files changed, 36 insertions(+), 15 deletions(-)
Comments
On 01/07/2015 04:17 PM, Pedro Alves wrote:
> On 01/05/2015 07:01 PM, Breazeal, Don wrote:
>>> # Start a set of programs running and then wait for a bit, to be sure
>>> # that they can be attached to. Return a list of the processes' PIDs.
>>>
>>> proc spawn_wait_for_attach { executable_list } {
>>> set pid_list {}
>>>
>>> + if ![can_spawn_for_attach] {
>>> + error "can't spawn for attach with this target/board"
>>> + }
>>
>> Should this be calling "error", or should it call something like
>> "untested" or "unsupported", since it isn't expected to work in these cases?
>
> The idea is that all .exp files that use spawn_wait_for_attach
> would have already checked can_spawn_for_attach early, and skipped the
> tests if false. That makes is a test bug to see a call to
> spawn_wait_for_attach if can_spawn_for_attach is false.
>
> I should have really split those hunks out to a separate patch and
> added calls to can_spawn_for_attach in all tests that are using
> spawn_wait_for_attach already. Like below. WDYT?
>
> (There are probably other attach tests that don't use
> spawn_wait_for_attach that need the can_spawn_for_attach too.
> We can do this incrementally.)
I went ahead and pushed this to unblock the parent series.
> gdb/testsuite/
> 2015-01-09 Pedro Alves <palves@redhat.com>
>
> * lib/gdb.exp (can_spawn_for_attach): New procedure.
> (spawn_wait_for_attach): Error out if can_spawn_for_attach returns
> false.
> * gdb.base/attach.exp: Use can_spawn_for_attach instead of
> checking whether the target board is remote.
> * gdb.multi/multi-attach.exp: Likewise.
> * gdb.python/py-sync-interp.exp: Likewise.
> * gdb.server/ext-attach.exp: Likewise.
> * gdb.python/py-prompt.exp: Use can_spawn_for_attach before the
> tests that need to attach, instead of checking whether the target
> board is remote at the top of the file.
Thanks,
Pedro Alves
On Friday, January 09 2015, Pedro Alves wrote:
> On 01/07/2015 04:17 PM, Pedro Alves wrote:
>> On 01/05/2015 07:01 PM, Breazeal, Don wrote:
>>>> # Start a set of programs running and then wait for a bit, to be sure
>>>> # that they can be attached to. Return a list of the processes' PIDs.
>>>>
>>>> proc spawn_wait_for_attach { executable_list } {
>>>> set pid_list {}
>>>>
>>>> + if ![can_spawn_for_attach] {
>>>> + error "can't spawn for attach with this target/board"
>>>> + }
>>>
>>> Should this be calling "error", or should it call something like
>>> "untested" or "unsupported", since it isn't expected to work in these cases?
>>
>> The idea is that all .exp files that use spawn_wait_for_attach
>> would have already checked can_spawn_for_attach early, and skipped the
>> tests if false. That makes is a test bug to see a call to
>> spawn_wait_for_attach if can_spawn_for_attach is false.
>>
>> I should have really split those hunks out to a separate patch and
>> added calls to can_spawn_for_attach in all tests that are using
>> spawn_wait_for_attach already. Like below. WDYT?
>>
>> (There are probably other attach tests that don't use
>> spawn_wait_for_attach that need the can_spawn_for_attach too.
>> We can do this incrementally.)
>
> I went ahead and pushed this to unblock the parent series.
Hey Pedro,
Buildbot (which is running only internally so far, but will hopefully be
deployed this week) "caught" this when building in x86_64 (Fedora 21)
and testing the native-gdbserver variant (both x86_64 and x86). When
you run the test on the gdb.python/ directory, you see that it stales
when it reaches the gdb.python/py-section-script.exp testcase.
Buildbot's gdb.log specifically has:
Running ../../../binutils-gdb/gdb/testsuite/gdb.python/py-section-script.exp ...
ERROR: (timeout) GDB never initialized after 10 seconds.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print ('test') to GDB.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print (sys.version_info[0]) to GDB.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print (sys.version_info[1]) to GDB.
ERROR: no fileid for gdbuild
ERROR: no fileid for gdbuild
...
(this goes on and on, for several testcases)
I still did not debug this (intend to do so tomorrow, if you don't see
this before I start my day), but running a simple git-bisect showed me
that this specific commit is the culprit.
Cheers,
On 01/12/2015 04:43 AM, Sergio Durigan Junior wrote:
>
> Buildbot (which is running only internally so far, but will hopefully be
> deployed this week) "caught" this when building in x86_64 (Fedora 21)
> and testing the native-gdbserver variant (both x86_64 and x86). When
> you run the test on the gdb.python/ directory, you see that it stales
> when it reaches the gdb.python/py-section-script.exp testcase.
> Buildbot's gdb.log specifically has:
>
> Running ../../../binutils-gdb/gdb/testsuite/gdb.python/py-section-script.exp ...
> ERROR: (timeout) GDB never initialized after 10 seconds.
> ERROR: no fileid for gdbuild
> ERROR: Couldn't send python print ('test') to GDB.
> ERROR: no fileid for gdbuild
> ERROR: Couldn't send python print (sys.version_info[0]) to GDB.
> ERROR: no fileid for gdbuild
> ERROR: Couldn't send python print (sys.version_info[1]) to GDB.
> ERROR: no fileid for gdbuild
> ERROR: no fileid for gdbuild
> ...
> (this goes on and on, for several testcases)
>
Here's what I get:
$ make check RUNTESTFLAGS="--target_board=native-gdbserver gdb.python/py-section-script.exp"
...
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.python/py-section-script.exp ...
=== gdb Summary ===
# of expected passes 7
...
> I still did not debug this (intend to do so tomorrow, if you don't see
> this before I start my day), but running a simple git-bisect showed me
> that this specific commit is the culprit.
Odd, my commit did not touch this file. Actually, the test does not
use "attach" at all.
Thanks,
Pedro Alves
On Monday, January 12 2015, Pedro Alves wrote:
> On 01/12/2015 04:43 AM, Sergio Durigan Junior wrote:
>>
>> Buildbot (which is running only internally so far, but will hopefully be
>> deployed this week) "caught" this when building in x86_64 (Fedora 21)
>> and testing the native-gdbserver variant (both x86_64 and x86). When
>> you run the test on the gdb.python/ directory, you see that it stales
>> when it reaches the gdb.python/py-section-script.exp testcase.
>> Buildbot's gdb.log specifically has:
>>
>> Running ../../../binutils-gdb/gdb/testsuite/gdb.python/py-section-script.exp ...
>> ERROR: (timeout) GDB never initialized after 10 seconds.
>> ERROR: no fileid for gdbuild
>> ERROR: Couldn't send python print ('test') to GDB.
>> ERROR: no fileid for gdbuild
>> ERROR: Couldn't send python print (sys.version_info[0]) to GDB.
>> ERROR: no fileid for gdbuild
>> ERROR: Couldn't send python print (sys.version_info[1]) to GDB.
>> ERROR: no fileid for gdbuild
>> ERROR: no fileid for gdbuild
>> ...
>> (this goes on and on, for several testcases)
>>
>
> Here's what I get:
>
> $ make check RUNTESTFLAGS="--target_board=native-gdbserver gdb.python/py-section-script.exp"
> ...
> Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.python/py-section-script.exp ...
>
> === gdb Summary ===
>
> # of expected passes 7
> ...
Running the testcase alone seems to be fine. The problem happens when
you run the entire gdb.python/ directory:
make check RUNTESTFLAGS="--target_board=native-gdbserver --directory=gdb.python"
On 01/12/2015 04:55 PM, Sergio Durigan Junior wrote:
> Running the testcase alone seems to be fine. The problem happens when
> you run the entire gdb.python/ directory:
>
> make check RUNTESTFLAGS="--target_board=native-gdbserver --directory=gdb.python"
Ah, yes. I see the bug. Will push a fix in a bit.
Thanks,
Pedro Alves
@@ -25,8 +25,7 @@ if { [istarget "hppa*-*-hpux*"] } {
return 0
}
-# are we on a target board
-if [is_remote target] then {
+if {![can_spawn_for_attach]} {
return 0
}
@@ -31,8 +31,7 @@ if [skip_shlib_tests] {
return 0
}
-# Are we on a target board? It is required for attaching to a process.
-if [is_remote target] {
+if {![can_spawn_for_attach]} {
return 0
}
@@ -19,8 +19,7 @@
standard_testfile
-# We need to use TCL's exec to get the pid.
-if [is_remote target] then {
+if {![can_spawn_for_attach]} {
return 0
}
@@ -18,11 +18,6 @@
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
load_lib prompt.exp
@@ -80,6 +75,10 @@ gdb_test "python print (\"'\" + str(p\[0\]) + \"'\")" "'$gdb_prompt_fail '" \
"prompt_hook argument is default prompt. 2"
gdb_exit
+if {![can_spawn_for_attach]} {
+ return 0
+}
+
set testpid [spawn_wait_for_attach $binfile]
set GDBFLAGS [concat $tmp_gdbflags " -ex \"set pagination off\""]
@@ -20,8 +20,7 @@
standard_testfile
-# We need to use TCL's exec to get the pid.
-if [is_remote target] then {
+if {![can_spawn_for_attach]} {
return 0
}
@@ -26,8 +26,7 @@ if { [skip_gdbserver_tests] } {
return 0
}
-# We need to use TCL's exec to get the pid.
-if [is_remote target] then {
+if {![can_spawn_for_attach]} {
return 0
}
@@ -3413,12 +3413,39 @@ proc gdb_exit { } {
catch default_gdb_exit
}
+# Return true if we can spawn a program on the target and attach to
+# it.
+
+proc can_spawn_for_attach { } {
+ # We use TCL's exec to get the inferior's pid.
+ if [is_remote target] then {
+ return 0
+ }
+
+ # The "attach" command doesn't make sense when the target is
+ # stub-like, where GDB finds the program already started on
+ # initial connection.
+ if {[target_info exists use_gdb_stub]} {
+ return 0
+ }
+
+ # Assume yes.
+ return 1
+}
+
# Start a set of programs running and then wait for a bit, to be sure
# that they can be attached to. Return a list of the processes' PIDs.
+# It's a test error to call this when [can_spawn_for_attach] is false.
proc spawn_wait_for_attach { executable_list } {
set pid_list {}
+ if ![can_spawn_for_attach] {
+ # The caller should have checked can_spawn_for_attach itself
+ # before getting here.
+ error "can't spawn for attach with this target/board"
+ }
+
foreach {executable} $executable_list {
lappend pid_list [eval exec $executable &]
}