This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.21 - Machine maintainers, please test your machines.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Chris Metcalf <cmetcalf at ezchip dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, "H.J. Lu" <hjl dot tools at gmail dot com>, David Miller <davem at davemloft dot net>, Richard Henderson <rth at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, Andreas Schwab <schwab at suse dot de>, "Joseph S. Myers" <joseph at codesourcery dot com>, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>, Thomas Schwinge <thomas at codesourcery dot com>, Marcus Shawcroft <marcus dot shawcroft at linaro dot org>, David Holsgrove <david dot holsgrove at xilinx dot com>, Chung-Lin Tang <chunglin_tang at mentor dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Date: Sat, 24 Jan 2015 18:41:54 +0100
- Subject: Re: glibc 2.21 - Machine maintainers, please test your machines.
- Authentication-results: sourceware.org; auth=none
- References: <54C2BDD7 dot 7000304 at redhat dot com> <54C3B6D5 dot 3090308 at ezchip dot com> <1422119595 dot 29655 dot 42 dot camel at triegel dot csb>
On Sat, 2015-01-24 at 18:13 +0100, Torvald Riegel wrote:
> There might be another issue in the 32b variant of struct new_sem, which
> changed like this:
> - unsigned long int nwaiters;
> + int pad;
> + unsigned int nwaiters;
>
> I'll investigate this further. The size increase might be an issue.
It's not if "int" is 4 bytes long because sem_t is always at least 16
bytes, and we have 4 int fields in struct new_sem.
I went through all bits/semaphore.h and confirmed this. I believe this
could use some clean-up.
With the exception of m68k, alignment is always to "long int" (union of
long int and char[size-see-below]).
The size is 32B if WORDSIZE==64 and 16 otherwise on:
s390, x86, powerpc, mips, sparc, tile
The size is fixed at 32B on:
alpha, aarch64, ia64
The size is fixed at 16B on:
arm, microblaze, nios, hppa, sh
m68k is an outlier. It sets the size to 16B but alignment like that:
long int __align __attribute__ ((__aligned__ (4)))
I don't know anything about m68k, and there's no comment why that is
different. Does anyone know?
The size is also not an issue if 64b atomic ops are used because then we
have uint64_t + int + int, which should also be 16B in sum on all archs
I believe. We could remove the padding field though on new_sem.
In retrospect, I do vaguely remember doing this same exercise before. I
guess I should have added a comment, and definitely should do so now.
I'm also wondering how we can improve this in the future. If we want to
have more generic code, and be able to refactor old arch-specific code
into generic code, we need to know more about type alignment and size
issues. Any suggestions for how to make this easier?
Going for either ILP32 or LP64 might be one part to this.