Re: sparc64 vs. gcc 4.8

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Fri, 3 Oct 2014, Erik Fair wrote:

> However, if sparc64's memory barrier implementation has issues, that's certainly fundamental enough to require immediate attention. Eduardo, can you be more specific about what you thought was wrong with the existing implementation?

You misunderstand.  I'm not suggesting the sparc64 memory barrier 
implementation has issues.  I'm suggesting the mutex design itself has 
issues.  If you look at the way it's put together, it's designed around 
x86-style memory ordering and won't work with machines that have more 
relaxed memory semantics.  To fix this, the types and locations where the 
in the memory synchronization routines are called from the locking 
primitives needs to be changed.

The issues with gcc 4.8 may be completely unrelated to the locking issues, 
since we are running the kernel in TSO mode and the memory semantics 
should be similar to x86.  However, if the new compiler is more aggressive 
about instruction reordering, it may cause the flaws in the mutex design 
to manifest themselves.  I'm just suggesting this is a good place to start 
looking for problems, especially since we run userland with more relaxed 
memory semantics.

Eduardo