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