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.


Reply via email to