[RFA] testsuite avoid tcl error in gdb.threads/gcore-thread.exp

[RFA] testsuite avoid tcl error in gdb.threads/gcore-thread.exp

[Pierre Muller]

  I get a tcl error on gdb.threads/gcore-thread.exp
because cygwin fails before, and the program exits
earlier than expected.
  When the test which is supposed
to set core_supported variable, no of the two variants is output,
but instead I get a message that I can't do this
without a running process.

gcore /usr/local/src/gdbcvs/build-norm/gdb/testsuite/gdb.threads/gcore.test
You can't do that without a process to debug.

  This results in the fact that the core_supported variable is
not set, and the
if {!$core_supported}
issues a tcl ERROR.


  The patch below, set core_supported to `0' before
testing for support at global level.
  Tested on gcc16 (it works again, hurrah!)
no changes.

  OK to commit?

Pierre Muller
Pascal language support maintainer for GDB

 

 2010-06-23  Pierre Muller  <muller@ics.u-strasbg.fr>

	* gcore-thread.exp (core_supported): Initialize variable to zero
	at global scope.
	(gdb_test_multiple): Only set CORE_SUPPORTED if test passes.


Index: src/gdb/testsuite/gdb.threads/gcore-thread.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/gcore-thread.exp,v
retrieving revision 1.17
diff -u -p -r1.17 gcore-thread.exp
--- src/gdb/testsuite/gdb.threads/gcore-thread.exp	2 Jun 2010 19:58:21
-0000	1.17
+++ src/gdb/testsuite/gdb.threads/gcore-thread.exp	23 Jun 2010 13:16:20
-0000
@@ -94,6 +94,9 @@ gdb_test "continue" "Continuing.*Breakpo
 
 set escapedfilename [string_to_regexp ${objdir}/${subdir}/gcore.test]
 # Drop corefile
+global core_supported
+set core_supported 0
+
 gdb_test_multiple "gcore ${objdir}/${subdir}/gcore.test" \
 	"save a corefile" \
 {
@@ -104,12 +107,9 @@ gdb_test_multiple "gcore ${objdir}/${sub
   }
   -re "Can't create a corefile\[\r\n\]+$gdb_prompt $" {
     unsupported "save a corefile"
-    global core_supported
-    set core_supported 0
   }
 }
 
-global core_supported
 if {!$core_supported} {
   return -1
 }

Re: [RFA] testsuite avoid tcl error in gdb.threads/gcore-thread.exp

[Pedro Alves]

On Wednesday 23 June 2010 14:59:09, Pierre Muller wrote:

>   Tested on gcc16 (it works again, hurrah!)
> no changes.

I, and more importantly I guess anyone reading the archives in a
few years, don't know what gcc16 is.  I guess it to be a machine in
the gcc compile farm, and I guess it to be running linux, but I don't
know for sure.  I don't know if it is x86, x86-64 or something else.  Can
you please state x86_64-linux, or something like that instead of
assuming everyone else is using the gcc compile farm?

>   OK to commit?

Yes, thanks.  I was going to suggest fixing gcore.exp too, but
it was already fixed similarly at some point:

2007-05-14  Markus Deuling  <deuling@de.ibm.com>

        * gdb.base/gcore.exp: Initialize variable core_supported.

>  set escapedfilename [string_to_regexp ${objdir}/${subdir}/gcore.test]
>  # Drop corefile
> +global core_supported
> +set core_supported 0
> +

Pedantically, you don't need that "global" statement anymore.

-- 
Pedro Alves

RE: [RFA] testsuite avoid tcl error in gdb.threads/gcore-thread.exp

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Pedro Alves
> Envoyé : Wednesday, June 23, 2010 4:42 PM
> À : gdb-patches@sourceware.org
> Cc : Pierre Muller
> Objet : Re: [RFA] testsuite avoid tcl error in gdb.threads/gcore-
> thread.exp
> 
> On Wednesday 23 June 2010 14:59:09, Pierre Muller wrote:
> 
> >   Tested on gcc16 (it works again, hurrah!)
> > no changes.
> 
> I, and more importantly I guess anyone reading the archives in a
> few years, don't know what gcc16 is.  I guess it to be a machine in
> the gcc compile farm, and I guess it to be running linux, but I don't
> know for sure.  I don't know if it is x86, x86-64 or something else.
> Can
> you please state x86_64-linux, or something like that instead of
> assuming everyone else is using the gcc compile farm?

  Sorry, 
yes indeed gcc16 is just one of the machine of the gcc compile farm,
and it is a linux box base on a x86_64 CPU.
 
> >   OK to commit?
> 
> Yes, thanks. 

Thanks for the approval, patch committed.

> I was going to suggest fixing gcore.exp too, but
> it was already fixed similarly at some point:
> 
> 2007-05-14  Markus Deuling  <deuling@de.ibm.com>
> 
>         * gdb.base/gcore.exp: Initialize variable core_supported.
> 
> >  set escapedfilename [string_to_regexp
> ${objdir}/${subdir}/gcore.test]
> >  # Drop corefile
> > +global core_supported
> > +set core_supported 0
> > +
> 
> Pedantically, you don't need that "global" statement anymore.

  I still didn't really understand this:
  when I run a testsuite with
'make check'.
All individual tests are run from runtest script
which itself uses runtest procedure to execute
each .exp file using the source command.
  Thus I was thinking that the code 
inside each .exp  file was not at global level,
but only at 'runtest procedure level', and I am not even sure
which level that procedure runs.
  Could someone explain to me why we are for sure
at global level when a .exp file is sourced?

Pierre

Re: [RFA] testsuite avoid tcl error in gdb.threads/gcore-thread.exp

[Doug Evans]

On Wed, Jun 23, 2010 at 8:31 AM, Pierre Muller
<pierre.muller@ics-cnrs.unistra.fr> wrote:
>> Pedantically, you don't need that "global" statement anymore.
>
>  I still didn't really understand this:
>  when I run a testsuite with
> 'make check'.
> All individual tests are run from runtest script
> which itself uses runtest procedure to execute
> each .exp file using the source command.
>  Thus I was thinking that the code
> inside each .exp  file was not at global level,
> but only at 'runtest procedure level', and I am not even sure
> which level that procedure runs.
>  Could someone explain to me why we are for sure
> at global level when a .exp file is sourced?

Because runtest invokes the .exp file as:

        if { [catch "uplevel #0 source $test_file_name"] == 1 } {