Re: Linux Sparc FPU register corruption

[Aurelien Jarno <aurelien@aurel32.net>]

On 2015-06-09 12:02, David Miller wrote:
> From: James Y Knight <jyknight@google.com>
> Date: Tue, 9 Jun 2015 08:13:58 -0400
> 
> > Um, but my test isn't testing what is being stored to memory at
> > all. It is storing to memory and **never loading from the memory
> > after**. Why would writing FROM fp registers TO memory corrupt the
> > *registers* due to a missing memory barrier?
> 
> The memory barrier is necessary for two reasons, only one of them is
> to handle the asynchronousness of the memory operations.
> 
> The other reason is that there are strict rules for accessing the FPU
> register file around block loads and stores.
> 
> Therefore if you don't do the proper memory barriers you can get
> corrupted FPU register as well as memory contents.
> 
> And complicating things even more, what you can get away with is
> different on every single cpu variant.  That's why I really wish

So it means the userland code doesn't run the same on the various
CPU. How are we supposed to do with static binaries?

> debian didn't disable multiarch as that makes the code use the
> UltraSPARC-I/II/III memcpy, which might not be %100 kosher on
> Niagara-T1 and later.

The UltraSPARC-I/II/III memcpy code might have issues, but it clearly
works a lot better than the Niagara-T1 code on a Niagara-T1 machine.
Disabling multiarch support improves a lot the stability on these
machines.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net