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)

Message ID 54AD5BFC.2030906@redhat.com
State New, archived
Headers

Commit Message

Pedro Alves Jan. 7, 2015, 4:17 p.m. UTC
  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

Pedro Alves Jan. 9, 2015, 11:24 a.m. UTC | #1
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
  
Sergio Durigan Junior Jan. 12, 2015, 4:43 a.m. UTC | #2
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,
  
Pedro Alves Jan. 12, 2015, 11:15 a.m. UTC | #3
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
  
Sergio Durigan Junior Jan. 12, 2015, 4:55 p.m. UTC | #4
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"
  
Pedro Alves Jan. 12, 2015, 5 p.m. UTC | #5
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
  

Patch

diff --git a/gdb/testsuite/gdb.base/attach.exp b/gdb/testsuite/gdb.base/attach.exp
index 5fb5c53..96e5df4 100644
--- a/gdb/testsuite/gdb.base/attach.exp
+++ b/gdb/testsuite/gdb.base/attach.exp
@@ -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
 }
 
diff --git a/gdb/testsuite/gdb.base/solib-overlap.exp b/gdb/testsuite/gdb.base/solib-overlap.exp
index 7486b07..71ff175 100644
--- a/gdb/testsuite/gdb.base/solib-overlap.exp
+++ b/gdb/testsuite/gdb.base/solib-overlap.exp
@@ -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
 }
 
diff --git a/gdb/testsuite/gdb.multi/multi-attach.exp b/gdb/testsuite/gdb.multi/multi-attach.exp
index eaff2c9..7f2ac80 100644
--- a/gdb/testsuite/gdb.multi/multi-attach.exp
+++ b/gdb/testsuite/gdb.multi/multi-attach.exp
@@ -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
 }
 
diff --git a/gdb/testsuite/gdb.python/py-prompt.exp b/gdb/testsuite/gdb.python/py-prompt.exp
index 1c53c03..3d1f264 100644
--- a/gdb/testsuite/gdb.python/py-prompt.exp
+++ b/gdb/testsuite/gdb.python/py-prompt.exp
@@ -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\""]
diff --git a/gdb/testsuite/gdb.python/py-sync-interp.exp b/gdb/testsuite/gdb.python/py-sync-interp.exp
index d62f966..7efafd1 100644
--- a/gdb/testsuite/gdb.python/py-sync-interp.exp
+++ b/gdb/testsuite/gdb.python/py-sync-interp.exp
@@ -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
 }
 
diff --git a/gdb/testsuite/gdb.server/ext-attach.exp b/gdb/testsuite/gdb.server/ext-attach.exp
index 9baeeb7..11f5a20 100644
--- a/gdb/testsuite/gdb.server/ext-attach.exp
+++ b/gdb/testsuite/gdb.server/ext-attach.exp
@@ -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
 }
 
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 08087f2..4386da8 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -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 &]
     }