[patch/rfa] Don't assume SIG32 in staticthreads.exp

[patch/rfa] Don't assume SIG32 in staticthreads.exp

[Randolph Chung]

SIGRTMIN is 37 on hppa-linux and hpux, instead of 32, which was assumed
by this test.

also depending on the version of libc, etc, "sem_post" may have a
different internal symbolic name. for example on my test setup it shows
up as "__new_sem_post". This seems to be reasonable, so i've relaxed the
name checking slightly.

Tested on hppa-linux. ok to apply?

randolph


2004-11-23  Randolph Chung  <tausq@debian.org>

	testsuite/

	* gdb.threads/staticthreads.exp: Override signal to check for hppa.
	Slightly relex "sem_post" name checking.


Index: testsuite/gdb.threads/staticthreads.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/staticthreads.exp,v
retrieving revision 1.1
diff -u -p -r1.1 staticthreads.exp
--- testsuite/gdb.threads/staticthreads.exp	1 Sep 2004 18:02:45 -0000	1.1
+++ testsuite/gdb.threads/staticthreads.exp	23 Nov 2004 22:42:11 -0000
@@ -62,10 +62,17 @@ gdb_test_multiple "continue" "$test" {
 # See if handle SIG32 helps (a little) with a static multi-threaded
 # program.
 
+set sig "SIG32"
+
+# SIGRTMIN is 37 on hppa-linux and hpux
+if [istarget hppa*-*-*] {
+  set sig "SIG37"
+}
+
 rerun_to_main
-gdb_test "handle SIG32 nostop noprint pass"
-set test "Handle SIG32 helps"
-gdb_test "continue" " sem_post .*" "handle SIG32 helps"
+gdb_test "handle $sig nostop noprint pass"
+set test "Handle $sig helps"
+gdb_test "continue" " .*sem_post .*" "handle $sig helps"
 
 
 # See if info threads produces anything approaching a thread list.
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [patch/rfa] Don't assume SIG32 in staticthreads.exp

[Randolph Chung]

ping?

In reference to a message from Randolph Chung, dated Nov 23:
> SIGRTMIN is 37 on hppa-linux and hpux, instead of 32, which was assumed
> by this test.
> 
> also depending on the version of libc, etc, "sem_post" may have a
> different internal symbolic name. for example on my test setup it shows
> up as "__new_sem_post". This seems to be reasonable, so i've relaxed the
> name checking slightly.
> 
> Tested on hppa-linux. ok to apply?
> 
> randolph
> 
> 
> 2004-11-23  Randolph Chung  <tausq@debian.org>
> 
> 	testsuite/
> 
> 	* gdb.threads/staticthreads.exp: Override signal to check for hppa.
> 	Slightly relex "sem_post" name checking.
> 
> 
> Index: testsuite/gdb.threads/staticthreads.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/staticthreads.exp,v
> retrieving revision 1.1
> diff -u -p -r1.1 staticthreads.exp
> --- testsuite/gdb.threads/staticthreads.exp	1 Sep 2004 18:02:45 -0000	1.1
> +++ testsuite/gdb.threads/staticthreads.exp	23 Nov 2004 22:42:11 -0000
> @@ -62,10 +62,17 @@ gdb_test_multiple "continue" "$test" {
>  # See if handle SIG32 helps (a little) with a static multi-threaded
>  # program.
>  
> +set sig "SIG32"
> +
> +# SIGRTMIN is 37 on hppa-linux and hpux
> +if [istarget hppa*-*-*] {
> +  set sig "SIG37"
> +}
> +
>  rerun_to_main
> -gdb_test "handle SIG32 nostop noprint pass"
> -set test "Handle SIG32 helps"
> -gdb_test "continue" " sem_post .*" "handle SIG32 helps"
> +gdb_test "handle $sig nostop noprint pass"
> +set test "Handle $sig helps"
> +gdb_test "continue" " .*sem_post .*" "handle $sig helps"
>  
>  
>  # See if info threads produces anything approaching a thread list.
> -- 
> Randolph Chung
> Debian GNU/Linux Developer, hppa/ia64 ports
> http://www.tausq.org/
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [patch/rfa] Don't assume SIG32 in staticthreads.exp

[Daniel Jacobowitz]

On Tue, Nov 30, 2004 at 10:57:40PM -0800, Randolph Chung wrote:
> ping?

This patch is fine.  Sorry about the delay.

> 
> In reference to a message from Randolph Chung, dated Nov 23:
> > SIGRTMIN is 37 on hppa-linux and hpux, instead of 32, which was assumed
> > by this test.
> > 
> > also depending on the version of libc, etc, "sem_post" may have a
> > different internal symbolic name. for example on my test setup it shows
> > up as "__new_sem_post". This seems to be reasonable, so i've relaxed the
> > name checking slightly.
> > 
> > Tested on hppa-linux. ok to apply?
> > 
> > randolph
> > 
> > 
> > 2004-11-23  Randolph Chung  <tausq@debian.org>
> > 
> > 	testsuite/
> > 
> > 	* gdb.threads/staticthreads.exp: Override signal to check for hppa.
> > 	Slightly relex "sem_post" name checking.
> > 
> > 
> > Index: testsuite/gdb.threads/staticthreads.exp
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/staticthreads.exp,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 staticthreads.exp
> > --- testsuite/gdb.threads/staticthreads.exp	1 Sep 2004 18:02:45 -0000	1.1
> > +++ testsuite/gdb.threads/staticthreads.exp	23 Nov 2004 22:42:11 -0000
> > @@ -62,10 +62,17 @@ gdb_test_multiple "continue" "$test" {
> >  # See if handle SIG32 helps (a little) with a static multi-threaded
> >  # program.
> >  
> > +set sig "SIG32"
> > +
> > +# SIGRTMIN is 37 on hppa-linux and hpux
> > +if [istarget hppa*-*-*] {
> > +  set sig "SIG37"
> > +}
> > +
> >  rerun_to_main
> > -gdb_test "handle SIG32 nostop noprint pass"
> > -set test "Handle SIG32 helps"
> > -gdb_test "continue" " sem_post .*" "handle SIG32 helps"
> > +gdb_test "handle $sig nostop noprint pass"
> > +set test "Handle $sig helps"
> > +gdb_test "continue" " .*sem_post .*" "handle $sig helps"
> >  
> >  
> >  # See if info threads produces anything approaching a thread list.
> > -- 
> > Randolph Chung
> > Debian GNU/Linux Developer, hppa/ia64 ports
> > http://www.tausq.org/
> -- 
> Randolph Chung
> Debian GNU/Linux Developer, hppa/ia64 ports
> http://www.tausq.org/
> 

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [patch/rfa] Don't assume SIG32 in staticthreads.exp

[Daniel Jacobowitz]

On Sun, Mar 27, 2005 at 07:01:07PM -0500, Daniel Jacobowitz wrote:
> On Tue, Nov 30, 2004 at 10:57:40PM -0800, Randolph Chung wrote:
> > ping?
> 
> This patch is fine.  Sorry about the delay.

In fact, I've committed it myself.


-- 
Daniel Jacobowitz
CodeSourcery, LLC