stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: STDCXX-1072 SPARC V8 mutex alignment requirements
Date Fri, 28 Sep 2012 15:47:28 GMT
On 09/28/2012 09:32 AM, 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.
> 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.
> 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.

Alignment does matter for binary compatibility but since the patch
increases it, and since the actual alignment for an object is
guaranteed to be at least as strict as the requirement for its
type, I think the change is both backward and forward compatible.
The latter only for correctly written programs that aren't relying
on the actual alignment being greater than required. Since this is
an internal helper used only by stdcxx classes, I don't think we
need to worry about such programs.


View raw message