[PATCH] m68: Enforce 4-byte alignment on internal locks (BZ #29537)

[Adhemerval Zanella Netto]

On 30/08/22 13:32, Richard Henderson wrote:
> On 8/30/22 06:35, Adhemerval Zanella via Libc-alpha wrote:
>> The HPPA also requires a 16-byte alignment for locks, although it is
>> just a historical artifact to keep compatibility with old
>> implementation.
>> ---
>>   sysdeps/nptl/libc-lockP.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/sysdeps/nptl/libc-lockP.h b/sysdeps/nptl/libc-lockP.h
>> index d3a6837fd2..9efe962588 100644
>> --- a/sysdeps/nptl/libc-lockP.h
>> +++ b/sysdeps/nptl/libc-lockP.h
>> @@ -34,7 +34,7 @@
>>   #include <tls.h>
>>     /* Mutex type.  */
>> -typedef int __libc_lock_t;
>> +typedef int __libc_lock_t __LOCK_ALIGNMENT;
> 
> As Carlos explained, hppa doesn't require 16-byte alignment for kernel-assisted CAS.
> 
> I was on my way towards testing
> 
> -/* Mutex type.  */
> 
> -typedef int __libc_lock_t;
> 
> +/* Mutex type.
> 
> +   It is a requirement of the futex interface that the data be
> 
> +   naturally aligned.  This is almost always already the case
> 
> +   for 'int', but some older ABIs, e.g. m68k, do not.
> 
> +   The pthread types will have been aligned by __LOCK_ALIGNMENT.  */
> 
> +typedef int __libc_lock_t __attribute__((aligned(4)));
> 
> 
> 
> 
> r~

I don't have a strong preference, using __LOCK_ALIGNMENT at least is a no-op
for other architectures (although it most likely won't change anything assuming
int has 4-bytes alignment as usual).