stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <>
Subject Re: STDCXX-1072 SPARC V8 mutex alignment requirements
Date Fri, 28 Sep 2012 17:47:50 GMT
On 09/28/12 11:32, Travis Vitek wrote:
>> -----Original Message-----
>> From: Liviu Nicoara
>> Sent: Friday, September 28, 2012 5:29 AM
>> In short, my reading about this issue is that the kernel patch changed
>> the alignment of the userland mutex objects from a machine word to a
>> double-word boundary. No changes are required of the users who use such
>> objects in their programs unless users create mutex objects in buffers
>> which may not be aligned on a proper boundary.
> Your reading of this is consistent with my previous understanding of the problem, so
that is good.
>> I still don't have access to a SPARC machine. Any feed-back and/or
>> SPARC build results are more than welcome!
> I can provide build results for SPARCV9 if we want them, but I thought that the problem
only came up on 32-bit SPARCV8 builds.

I guess a -xarch=sparcv8 build will do. It is quite unlikely anybody has a real 32-bit SPARC

> The patch assumes the type `long double' exists on every platform. While I do believe
that it is available everywhere, we have lots of conditional code guarding its use in the
library now. If we are going to use `long double' in this context, we should guard it with
_RWSTD_NO_LONG_DOUBLE. I think an even cleaner solution is to switch to using __rw_aligned_buffer
instead. It gives us a single point of failure for alignment issues like this, and it makes
the code self-documenting and easier to read.

I took a cue from an alignment in the rw/_mutex.h code there. I'll do better.

> As for your concerns about binary compatibility, I think that everything should be okay.
We aren't changing the size of anything that is being passed around, we're just changing its
alignment. I could be wrong, but I'm pretty sure that we're safe.

The library object sizes and layouts will change with or without our patch. Before the kernel
patch our objects will have one layout and size and different ones afterwards. E.g.:

struct locale {
     int c;
     pthread_mutex_t lock;

before kernel patching you'd have no padding between the members. That's what I thought when
firing that second post about compatibility.


View raw message