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.
Martin
