Re: RISC-V glibc port v2

[Palmer Dabbelt <palmer@dabbelt.com>]

On Wed, 20 Dec 2017 13:11:02 PST (-0800), joseph@codesourcery.com wrote:
> On Tue, 19 Dec 2017, Palmer Dabbelt wrote:
>
>> * Should we have padding in __pthread_rwlock_arch_t?  I assume the padding on
>>   other architectures is there for ABI reasons and shouldn't be necessary for
>>   new ports, but the ports I usually rely on all have excatly the same padding
>>   so I'm worried there's another reason for this.
>
> The size was probably originally chosen to be the same as used by
> Linuxthreads.  Since then, there's been at least one rwlock rewrite that
> increased the amount of space that's padding.
>
> On the whole I'd say it's safest to have that padding on RISC-V as well,
> in case there are any more rewrites in future, since it's possible a
> rewrite could increase the amount of space used as well as decreasing it,
> and so if one architecture makes the type smaller than others that could
> complicate any such future change needing more space.

Sounds good.  I'll add a comment

diff --git a/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h b/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h
index f15e024826ac..4fabc4a2cde2 100644
--- a/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h
+++ b/sysdeps/riscv/nptl/bits/pthreadtypes-arch.h
@@ -52,6 +52,10 @@
 #define __LOCK_ALIGNMENT
 #define __ONCE_ALIGNMENT

+/* There is a lot of padding in this structure.  While it's not strictly
+   necessary on RISC-V, we're going to leave it in to be on the safe side in
+   case it's needed in the future.  Most other architectures have the padding,
+   so this gives us the same extensibility as everyone else has.  */
 struct __pthread_rwlock_arch_t
 {
   unsigned int __readers;