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