[parisc-linux-cvs] lock alignment problem in glibc

[Alan Modra]

On Fri, 16 Mar 2001, Richard Hirst wrote:

> --- dl-fptr.c   2000/10/06 15:20:54     1.6
> +++ dl-fptr.c   2001/03/16 18:53:06
> @@ -30,7 +30,7 @@
>  # include <pt-machine.h>
>  
>  /* Remember, we use 0 to mean that a lock is taken on PA-RISC. */
> -static int __hppa_fptr_lock = 1;
> +static int __attribute__((aligned(16))) __hppa_fptr_lock = 1;
>  #endif
>  
>  /* Because ld.so is now versioned, these functions can be in their own

Hmm, does that work?  All other uses of __attribute__ I've seen apply to
the variable in question, not the type.  Even if it does work, the
following might be better, simply because it's the usual way to do things.
Please check before committing though!!!  I haven't even compiled this...

Index: sysdeps/hppa/dl-fptr.c
===================================================================
RCS file: /home/cvs/parisc/glibc/sysdeps/hppa/dl-fptr.c,v
retrieving revision 1.7
diff -u -p -r1.7 dl-fptr.c
--- dl-fptr.c	2001/03/16 18:58:18	1.7
+++ dl-fptr.c	2001/03/17 01:05:17
@@ -29,8 +29,9 @@
 #ifdef _LIBC_REENTRANT
 # include <pt-machine.h>
 
-/* Remember, we use 0 to mean that a lock is taken on PA-RISC. */
-static int __attribute__((aligned(16))) __hppa_fptr_lock = 1;
+/* Remember, we use 0 to mean that a lock is taken on PA-RISC.
+   Locks also must be 16 byte aligned on certain PA-RISC machines.  */
+static int __hppa_fptr_lock __attribute__ ((aligned (16))) = 1;
 #endif
 
 /* Because ld.so is now versioned, these functions can be in their own

-- 
Linuxcare