stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <nikko...@hates.ms>
Subject Re: STDCXX-1072 SPARC V8 mutex alignment requirements
Date Fri, 28 Sep 2012 17:47:50 GMT
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

Mime
View raw message