This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RISC-V glibc port v2

On Wed, 20 Dec 2017 13:11:02 PST (-0800), 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 @@

+/* 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;

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]