[RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Elena Zannoni]

I was getting warnings when compiling the test on 64-bit because of the casts.

/home/ezannoni/gdb-sources/src/gdb/testsuite/gdb.threads/schedlock.c: In function `main':
/home/ezannoni/gdb-sources/src/gdb/testsuite/gdb.threads/schedlock.c:21: warning: cast to pointer from integer of different size
/home/ezannoni/gdb-sources/src/gdb/testsuite/gdb.threads/schedlock.c:26: warning: cast to pointer from integer of different size
/home/ezannoni/gdb-sources/src/gdb/testsuite/gdb.threads/schedlock.c: In function `thread_function':
/home/ezannoni/gdb-sources/src/gdb/testsuite/gdb.threads/schedlock.c:32: warning: cast from pointer to integer of different size


Michael, Daniel?

elena

2003-04-08  Elena Zannoni  <ezannoni@redhat.com>

	* gdb.threads/schedlock.c: Cast to thread function argument to
	long, for 64-bit platforms.


Index: schedlock.c
===================================================================
RCS file: /cvs/uberbaum/gdb/testsuite/gdb.threads/schedlock.c,v
retrieving revision 1.2
diff -u -p -r1.2 schedlock.c
--- schedlock.c	23 Oct 2002 03:22:56 -0000	1.2
+++ schedlock.c	8 Apr 2003 20:56:31 -0000
@@ -18,18 +18,21 @@ int main() {
     for (i = 0; i < NUM; i++)
       {
 	args[i] = 1;
-	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
+	res = pthread_create(&threads[i],
+		             NULL,
+			     thread_function,
+			     (void *) (long) i);
       }
 
     /* schedlock.exp: last thread start.  */
     args[i] = 1;
-    thread_function ((void *) i);
+    thread_function ((void *) (long) i);
 
     exit(EXIT_SUCCESS);
 }
 
 void *thread_function(void *arg) {
-    int my_number = (int) arg;
+    int my_number = (long) arg;
     int *myp = &args[my_number];
 
     /* Don't run forever.  Run just short of it :)  */

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Daniel Jacobowitz]

On Tue, Apr 08, 2003 at 05:20:19PM -0400, Elena Zannoni wrote:
> 
> I was getting warnings when compiling the test on 64-bit because of the casts.
> 
> /home/ezannoni/gdb-sources/src/gdb/testsuite/gdb.threads/schedlock.c: In function `main':
> /home/ezannoni/gdb-sources/src/gdb/testsuite/gdb.threads/schedlock.c:21: warning: cast to pointer from integer of different size
> /home/ezannoni/gdb-sources/src/gdb/testsuite/gdb.threads/schedlock.c:26: warning: cast to pointer from integer of different size
> /home/ezannoni/gdb-sources/src/gdb/testsuite/gdb.threads/schedlock.c: In function `thread_function':
> /home/ezannoni/gdb-sources/src/gdb/testsuite/gdb.threads/schedlock.c:32: warning: cast from pointer to integer of different size
> 
> 
> Michael, Daniel?

Sigh, I was just sloppy writing this one.   Does it work if you pass
&args[i] instead of messing with my_number?  That's a little more
portable.

> 2003-04-08  Elena Zannoni  <ezannoni@redhat.com>
> 
> 	* gdb.threads/schedlock.c: Cast to thread function argument to
> 	long, for 64-bit platforms.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Tue, Apr 08, 2003 at 05:20:19PM -0400, Elena Zannoni wrote:
 > > 
 > > I was getting warnings when compiling the test on 64-bit because of the casts.
 > > 

 > 
 > Sigh, I was just sloppy writing this one.   Does it work if you pass
 > &args[i] instead of messing with my_number?  That's a little more
 > portable.
 > 

Ok, how about this? But now get_current_thread in schedlock.exp
doesn't work, because the output has changed. I am not sure I
understand what it should be doing now. There is no way to get the
thread number from the backtraces.

elena




Index: schedlock.c
===================================================================
RCS file: /cvs/uberbaum/gdb/testsuite/gdb.threads/schedlock.c,v
retrieving revision 1.2
diff -u -p -r1.2 schedlock.c
--- schedlock.c	23 Oct 2002 03:22:56 -0000	1.2
+++ schedlock.c	10 Apr 2003 14:00:41 -0000
@@ -18,19 +18,21 @@ int main() {
     for (i = 0; i < NUM; i++)
       {
 	args[i] = 1;
-	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
+	res = pthread_create(&threads[i],
+		             NULL,
+			     thread_function,
+			     (void *) &args[i]);
       }
 
     /* schedlock.exp: last thread start.  */
     args[i] = 1;
-    thread_function ((void *) i);
+    thread_function ((void *) &args[i]);
 
     exit(EXIT_SUCCESS);
 }
 
 void *thread_function(void *arg) {
-    int my_number = (int) arg;
-    int *myp = &args[my_number];
+    int *myp = (int *)arg;
 
     /* Don't run forever.  Run just short of it :)  */
     while (*myp > 0)

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Daniel Jacobowitz]

On Thu, Apr 10, 2003 at 10:12:28AM -0400, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > On Tue, Apr 08, 2003 at 05:20:19PM -0400, Elena Zannoni wrote:
>  > > 
>  > > I was getting warnings when compiling the test on 64-bit because of the casts.
>  > > 
> 
>  > 
>  > Sigh, I was just sloppy writing this one.   Does it work if you pass
>  > &args[i] instead of messing with my_number?  That's a little more
>  > portable.
>  > 
> 
> Ok, how about this? But now get_current_thread in schedlock.exp
> doesn't work, because the output has changed. I am not sure I
> understand what it should be doing now. There is no way to get the
> thread number from the backtraces.

Oh, you're right - sorry for the wild goose chase.  I think your
previous patch with the cast to long is OK then.  The test isn't
terribly portable but it should be portable enough for our use.

> 
> elena
> 
> 
> 
> 
> Index: schedlock.c
> ===================================================================
> RCS file: /cvs/uberbaum/gdb/testsuite/gdb.threads/schedlock.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 schedlock.c
> --- schedlock.c	23 Oct 2002 03:22:56 -0000	1.2
> +++ schedlock.c	10 Apr 2003 14:00:41 -0000
> @@ -18,19 +18,21 @@ int main() {
>      for (i = 0; i < NUM; i++)
>        {
>  	args[i] = 1;
> -	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
> +	res = pthread_create(&threads[i],
> +		             NULL,
> +			     thread_function,
> +			     (void *) &args[i]);
>        }
>  
>      /* schedlock.exp: last thread start.  */
>      args[i] = 1;
> -    thread_function ((void *) i);
> +    thread_function ((void *) &args[i]);
>  
>      exit(EXIT_SUCCESS);
>  }
>  
>  void *thread_function(void *arg) {
> -    int my_number = (int) arg;
> -    int *myp = &args[my_number];
> +    int *myp = (int *)arg;
>  
>      /* Don't run forever.  Run just short of it :)  */
>      while (*myp > 0)
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Andrew Cagney]

>  	args[i] = 1;
>> -	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
>> 

Try:

  (((char *) NULL) + i)

and what ever the reverse of that is ....

Andrew

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Andreas Schwab]

Andrew Cagney <ac131313@redhat.com> writes:

|> >  	args[i] = 1;
|> >> -	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
|> >> 
|> 
|> Try:
|> 
|>   (((char *) NULL) + i)
|> 
|> and what ever the reverse of that is ....

That is even less portable than the above.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Daniel Jacobowitz]

On Thu, Apr 10, 2003 at 05:16:05PM +0200, Andreas Schwab wrote:
> Andrew Cagney <ac131313@redhat.com> writes:
> 
> |> >  	args[i] = 1;
> |> >> -	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
> |> >> 
> |> 
> |> Try:
> |> 
> |>   (((char *) NULL) + i)
> |> 
> |> and what ever the reverse of that is ....
> 
> That is even less portable than the above.

Really?  What's non-portable about it?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Thu, Apr 10, 2003 at 05:16:05PM +0200, Andreas Schwab wrote:
 > > Andrew Cagney <ac131313@redhat.com> writes:
 > > 
 > > |> >  	args[i] = 1;
 > > |> >> -	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
 > > |> >> 
 > > |> 
 > > |> Try:
 > > |> 
 > > |>   (((char *) NULL) + i)
 > > |> 
 > > |> and what ever the reverse of that is ....
 > > 
 > > That is even less portable than the above.
 > 
 > Really?  What's non-portable about it?


Attempt #3....

Index: schedlock.c
===================================================================
RCS file: /cvs/uberbaum/gdb/testsuite/gdb.threads/schedlock.c,v
retrieving revision 1.2
diff -u -p -r1.2 schedlock.c
--- schedlock.c	23 Oct 2002 03:22:56 -0000	1.2
+++ schedlock.c	10 Apr 2003 16:04:37 -0000
@@ -18,18 +18,25 @@ int main() {
     for (i = 0; i < NUM; i++)
       {
 	args[i] = 1;
-	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
+	res = pthread_create(&threads[i],
+		             NULL,
+			     thread_function,
+			     (void *) (((char *) NULL) + i));
       }
 
     /* schedlock.exp: last thread start.  */
     args[i] = 1;
-    thread_function ((void *) i);
+    thread_function ((void *) (((char *) NULL) + i));
 
     exit(EXIT_SUCCESS);
 }
 
 void *thread_function(void *arg) {
-    int my_number = (int) arg;
+
+ /* Use sick pointer arithmetic trick, to get an offset which is a
+    long. This will be silently converted to an int, which is of
+    smaller size on 64-bit platforms.  */
+    int my_number =  (char *) arg - (char *) NULL;
     int *myp = &args[my_number];
 
     /* Don't run forever.  Run just short of it :)  */

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Andreas Schwab]

Daniel Jacobowitz <drow@mvista.com> writes:

|> On Thu, Apr 10, 2003 at 05:16:05PM +0200, Andreas Schwab wrote:
|> > Andrew Cagney <ac131313@redhat.com> writes:
|> > 
|> > |> >  	args[i] = 1;
|> > |> >> -	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
|> > |> >> 
|> > |> 
|> > |> Try:
|> > |> 
|> > |>   (((char *) NULL) + i)
|> > |> 
|> > |> and what ever the reverse of that is ....
|> > 
|> > That is even less portable than the above.
|> 
|> Really?  What's non-portable about it?

NULL is not an object, and the C standard does not define any meaning for
the above expression.  On the other hand, the effect of a cast from
integer to pointer is implementation-defined (although it might trap).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Andreas Schwab]

Elena Zannoni <ezannoni@redhat.com> writes:

|> Daniel Jacobowitz writes:
|>  > On Thu, Apr 10, 2003 at 05:16:05PM +0200, Andreas Schwab wrote:
|>  > > Andrew Cagney <ac131313@redhat.com> writes:
|>  > > 
|>  > > |> >  	args[i] = 1;
|>  > > |> >> -	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
|>  > > |> >> 
|>  > > |> 
|>  > > |> Try:
|>  > > |> 
|>  > > |>   (((char *) NULL) + i)
|>  > > |> 
|>  > > |> and what ever the reverse of that is ....
|>  > > 
|>  > > That is even less portable than the above.
|>  > 
|>  > Really?  What's non-portable about it?
|> 
|> 
|> Attempt #3....

IMHO the intermediate cast to long (or better intptr_t when available)
would be most portable.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Andrew Cagney]

> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> |> On Thu, Apr 10, 2003 at 05:16:05PM +0200, Andreas Schwab wrote:
> |> > Andrew Cagney <ac131313@redhat.com> writes:
> |> > 
> |> > |> >  	args[i] = 1;
> |> > |> >> -	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
> |> > |> >> 
> |> > |> 
> |> > |> Try:
> |> > |> 
> |> > |>   (((char *) NULL) + i)
> |> > |> 
> |> > |> and what ever the reverse of that is ....
> |> > 
> |> > That is even less portable than the above.
> |> 
> |> Really?  What's non-portable about it?
> 
> NULL is not an object, and the C standard does not define any meaning for
> the above expression.  On the other hand, the effect of a cast from
> integer to pointer is implementation-defined (although it might trap).

What about this then:

static char *null_char_pointer = NULL;

	(null_char_pointer + i)

and:

	(i - null_char_pointer)

:-)

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Daniel Jacobowitz]

On Thu, Apr 10, 2003 at 01:45:34PM -0400, Andrew Cagney wrote:
> >Daniel Jacobowitz <drow@mvista.com> writes:
> >
> >|> On Thu, Apr 10, 2003 at 05:16:05PM +0200, Andreas Schwab wrote:
> >|> > Andrew Cagney <ac131313@redhat.com> writes:
> >|> > 
> >|> > |> >  	args[i] = 1;
> >|> > |> >> -	res = pthread_create(&threads[i], NULL, thread_function, 
> >(void *)i);
> >|> > |> >> 
> >|> > |> 
> >|> > |> Try:
> >|> > |> 
> >|> > |>   (((char *) NULL) + i)
> >|> > |> 
> >|> > |> and what ever the reverse of that is ....
> >|> > 
> >|> > That is even less portable than the above.
> >|> 
> >|> Really?  What's non-portable about it?
> >
> >NULL is not an object, and the C standard does not define any meaning for
> >the above expression.  On the other hand, the effect of a cast from
> >integer to pointer is implementation-defined (although it might trap).
> 
> What about this then:
> 
> static char *null_char_pointer = NULL;
> 
> 	(null_char_pointer + i)
> 
> and:
> 
> 	(i - null_char_pointer)
> 
> :-)

Also not defined, for the same reason.  I believe the only pointer
outside of an object that's guaranteed to have any useful value is the
one which points just past the end of it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Thu, Apr 10, 2003 at 10:12:28AM -0400, Elena Zannoni wrote:
> > Daniel Jacobowitz writes:
> >  > On Tue, Apr 08, 2003 at 05:20:19PM -0400, Elena Zannoni wrote:
> >  > >
> >  > > I was getting warnings when compiling the test on 64-bit because of the casts.
> >  > >
> >
> >  >
> >  > Sigh, I was just sloppy writing this one.   Does it work if you pass
> >  > &args[i] instead of messing with my_number?  That's a little more
> >  > portable.
> >  >
> >
> > Ok, how about this? But now get_current_thread in schedlock.exp
> > doesn't work, because the output has changed. I am not sure I
> > understand what it should be doing now. There is no way to get the
> > thread number from the backtraces.
> 
> Oh, you're right - sorry for the wild goose chase.  I think your
> previous patch with the cast to long is OK then.  The test isn't
> terribly portable but it should be portable enough for our use.

Why don't you just declare 'i' a long and be done with it?


> > Index: schedlock.c
> > ===================================================================
> > RCS file: /cvs/uberbaum/gdb/testsuite/gdb.threads/schedlock.c,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 schedlock.c
> > --- schedlock.c       23 Oct 2002 03:22:56 -0000      1.2
> > +++ schedlock.c       10 Apr 2003 14:00:41 -0000
> > @@ -18,19 +18,21 @@ int main() {
> >      for (i = 0; i < NUM; i++)
> >        {
> >       args[i] = 1;
> > -     res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
> > +     res = pthread_create(&threads[i],
> > +                          NULL,
> > +                          thread_function,
> > +                          (void *) &args[i]);
> >        }
> >
> >      /* schedlock.exp: last thread start.  */
> >      args[i] = 1;
> > -    thread_function ((void *) i);
> > +    thread_function ((void *) &args[i]);
> >
> >      exit(EXIT_SUCCESS);
> >  }
> >
> >  void *thread_function(void *arg) {
> > -    int my_number = (int) arg;
> > -    int *myp = &args[my_number];
> > +    int *myp = (int *)arg;
> >
> >      /* Don't run forever.  Run just short of it :)  */
> >      while (*myp > 0)
> >
> >
> 
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Elena Zannoni]

Michael Snyder writes:
 > Daniel Jacobowitz wrote:
 > > 
 > > On Thu, Apr 10, 2003 at 10:12:28AM -0400, Elena Zannoni wrote:
 > > > Daniel Jacobowitz writes:
 > > >  > On Tue, Apr 08, 2003 at 05:20:19PM -0400, Elena Zannoni wrote:
 > > >  > >
 > > >  > > I was getting warnings when compiling the test on 64-bit because of the casts.
 > > >  > >
 > > >
 > > >  >
 > > >  > Sigh, I was just sloppy writing this one.   Does it work if you pass
 > > >  > &args[i] instead of messing with my_number?  That's a little more
 > > >  > portable.
 > > >  >
 > > >
 > > > Ok, how about this? But now get_current_thread in schedlock.exp
 > > > doesn't work, because the output has changed. I am not sure I
 > > > understand what it should be doing now. There is no way to get the
 > > > thread number from the backtraces.
 > > 
 > > Oh, you're right - sorry for the wild goose chase.  I think your
 > > previous patch with the cast to long is OK then.  The test isn't
 > > terribly portable but it should be portable enough for our use.
 > 
 > Why don't you just declare 'i' a long and be done with it?

Daniel? 

Index: schedlock.c
===================================================================
RCS file: /cvs/uberbaum/gdb/testsuite/gdb.threads/schedlock.c,v
retrieving revision 1.2
diff -u -p -r1.2 schedlock.c
--- schedlock.c	23 Oct 2002 03:22:56 -0000	1.2
+++ schedlock.c	15 Apr 2003 01:47:34 -0000
@@ -13,12 +13,15 @@ int main() {
     int res;
     pthread_t threads[NUM];
     void *thread_result;
-    int i;
+    long i;
 
     for (i = 0; i < NUM; i++)
       {
 	args[i] = 1;
-	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
+	res = pthread_create(&threads[i],
+		             NULL,
+			     thread_function,
+			     (void *) i);
       }
 
     /* schedlock.exp: last thread start.  */
@@ -29,7 +32,7 @@ int main() {
 }
 
 void *thread_function(void *arg) {
-    int my_number = (int) arg;
+    int my_number =  (long) arg;
     int *myp = &args[my_number];
 
     /* Don't run forever.  Run just short of it :)  */

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Daniel Jacobowitz]

On Mon, Apr 14, 2003 at 09:53:14PM -0400, Elena Zannoni wrote:
> Michael Snyder writes:
>  > Daniel Jacobowitz wrote:
>  > > 
>  > > On Thu, Apr 10, 2003 at 10:12:28AM -0400, Elena Zannoni wrote:
>  > > > Daniel Jacobowitz writes:
>  > > >  > On Tue, Apr 08, 2003 at 05:20:19PM -0400, Elena Zannoni wrote:
>  > > >  > >
>  > > >  > > I was getting warnings when compiling the test on 64-bit because of the casts.
>  > > >  > >
>  > > >
>  > > >  >
>  > > >  > Sigh, I was just sloppy writing this one.   Does it work if you pass
>  > > >  > &args[i] instead of messing with my_number?  That's a little more
>  > > >  > portable.
>  > > >  >
>  > > >
>  > > > Ok, how about this? But now get_current_thread in schedlock.exp
>  > > > doesn't work, because the output has changed. I am not sure I
>  > > > understand what it should be doing now. There is no way to get the
>  > > > thread number from the backtraces.
>  > > 
>  > > Oh, you're right - sorry for the wild goose chase.  I think your
>  > > previous patch with the cast to long is OK then.  The test isn't
>  > > terribly portable but it should be portable enough for our use.
>  > 
>  > Why don't you just declare 'i' a long and be done with it?
> 
> Daniel? 

Looks fine to me - portable enough for our purposes.

> Index: schedlock.c
> ===================================================================
> RCS file: /cvs/uberbaum/gdb/testsuite/gdb.threads/schedlock.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 schedlock.c
> --- schedlock.c	23 Oct 2002 03:22:56 -0000	1.2
> +++ schedlock.c	15 Apr 2003 01:47:34 -0000
> @@ -13,12 +13,15 @@ int main() {
>      int res;
>      pthread_t threads[NUM];
>      void *thread_result;
> -    int i;
> +    long i;
>  
>      for (i = 0; i < NUM; i++)
>        {
>  	args[i] = 1;
> -	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
> +	res = pthread_create(&threads[i],
> +		             NULL,
> +			     thread_function,
> +			     (void *) i);
>        }
>  
>      /* schedlock.exp: last thread start.  */
> @@ -29,7 +32,7 @@ int main() {
>  }
>  
>  void *thread_function(void *arg) {
> -    int my_number = (int) arg;
> +    int my_number =  (long) arg;
>      int *myp = &args[my_number];
>  
>      /* Don't run forever.  Run just short of it :)  */
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/TESTSUITE] build schedlock.c on 64-bit platforms

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Mon, Apr 14, 2003 at 09:53:14PM -0400, Elena Zannoni wrote:
 > > Michael Snyder writes:
 > >  > Daniel Jacobowitz wrote:
 > >  > > 
 > >  > > On Thu, Apr 10, 2003 at 10:12:28AM -0400, Elena Zannoni wrote:
 > >  > > > Daniel Jacobowitz writes:
 > >  > > >  > On Tue, Apr 08, 2003 at 05:20:19PM -0400, Elena Zannoni wrote:
 > >  > > >  > >
 > >  > > >  > > I was getting warnings when compiling the test on 64-bit because of the casts.
 > >  > > >  > >
 > >  > > >
 > >  > > >  >
 > >  > > >  > Sigh, I was just sloppy writing this one.   Does it work if you pass
 > >  > > >  > &args[i] instead of messing with my_number?  That's a little more
 > >  > > >  > portable.
 > >  > > >  >
 > >  > > >
 > >  > > > Ok, how about this? But now get_current_thread in schedlock.exp
 > >  > > > doesn't work, because the output has changed. I am not sure I
 > >  > > > understand what it should be doing now. There is no way to get the
 > >  > > > thread number from the backtraces.
 > >  > > 
 > >  > > Oh, you're right - sorry for the wild goose chase.  I think your
 > >  > > previous patch with the cast to long is OK then.  The test isn't
 > >  > > terribly portable but it should be portable enough for our use.
 > >  > 
 > >  > Why don't you just declare 'i' a long and be done with it?
 > > 
 > > Daniel? 
 > 
 > Looks fine to me - portable enough for our purposes.

ok, I committed it.


 > 
 > > Index: schedlock.c
 > > ===================================================================
 > > RCS file: /cvs/uberbaum/gdb/testsuite/gdb.threads/schedlock.c,v
 > > retrieving revision 1.2
 > > diff -u -p -r1.2 schedlock.c
 > > --- schedlock.c	23 Oct 2002 03:22:56 -0000	1.2
 > > +++ schedlock.c	15 Apr 2003 01:47:34 -0000
 > > @@ -13,12 +13,15 @@ int main() {
 > >      int res;
 > >      pthread_t threads[NUM];
 > >      void *thread_result;
 > > -    int i;
 > > +    long i;
 > >  
 > >      for (i = 0; i < NUM; i++)
 > >        {
 > >  	args[i] = 1;
 > > -	res = pthread_create(&threads[i], NULL, thread_function, (void *)i);
 > > +	res = pthread_create(&threads[i],
 > > +		             NULL,
 > > +			     thread_function,
 > > +			     (void *) i);
 > >        }
 > >  
 > >      /* schedlock.exp: last thread start.  */
 > > @@ -29,7 +32,7 @@ int main() {
 > >  }
 > >  
 > >  void *thread_function(void *arg) {
 > > -    int my_number = (int) arg;
 > > +    int my_number =  (long) arg;
 > >      int *myp = &args[my_number];
 > >  
 > >      /* Don't run forever.  Run just short of it :)  */
 > > 
 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer