[PATCH] [RFC] Emulate "lwsync" to run standard user land on e500 cores

[Yang James-RA8135]

Sorry for the formatting.  I'm not at my usual mailer.

From: Kumar Gala:
>On Oct 24, 2013, at 4:05 PM, James Yang wrote:
>> On Thu, 24 Oct 2013, Kumar Gala wrote:
>>> Than, I'd ask this be under a Kconfig option that is disabled by
>>> default.  Users should have to explicitly enable this so they know
>>> what they are doing.
>>
>>
>> I think it should be enabled by default, rather than disabled, so that
>> users would actually see a warning rather than get a sig 4.  Or, let
>> it not be Kconfig-able so that this doesn't become a problem any more.
>> (It's been 4 years since I sent to you an earlier version of this
>> patch.)
>
>And clearly most users don't seem terrible annoyed enough about 
>this issue to have concerns.  I don't see why making it a Kconfig 
>option impacts the small handful of people that happen to try 
> and run a more generic distro on e500 cores.


I would have to dispute that qualification of "most".  

This is not a distro issue. It's a libstdc++ portability issue. libstdc++ 
hardcodes lwsync unless __NO_LWSYNC__ is explicitly defined, 
which you only get with -mcpu=8540/-mcpu=8548.  When compiled 
for any powerpc target other than -mcpu=8540/-mcpu=8548, including
the default -mcpu=common,  libstdc++ will end up containing lwsync.  
There is no way to explicitly request libstdc++ to be built without lwsync
with an -mcpu target other than 8540/8548.

The issue is easily demonstrated by running a program that throws a 
C++ exception: __cxa_throw() is called, which has an lwsync.  This
results in an illegal instruction exception when run on an e500v1/e500v2.

Those users who insist on using a generic target for their compiler
will hit this problem, in particular, those who need to generate 
binary code that targets a wide range of powerpc targets, such as
generic distro.  It's unreasonable to require a user to recompile 
libstdc++ just to get functionality for a C++ program, since they would
have to provide two libstdc++.so along with some dynamic-linking hacks to
determine at runtime which one should be used.  Emulating lwsync 
does not prevent an e500v1/e500v2-targeted libstdc++ from providing
the optimal performance.


citation:

> > lwsync is embedded into the library unless __NO_LWSYNC__ is defined:
> > http://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/config/cpu/powerpc/atomic_word.h?revision=195701&view=markup#l30
> > -----------------------------------------------
> > #define _GLIBCXX_READ_MEM_BARRIER __asm __volatile
> > ("isync":::"memory")
> > #ifdef __NO_LWSYNC__
> > #define _GLIBCXX_WRITE_MEM_BARRIER __asm __volatile
> > ("sync":::"memory")
> > #else
> > #define _GLIBCXX_WRITE_MEM_BARRIER __asm __volatile
> > ("lwsync":::"memory")
> > #endif
> > -----------------------------------------------
> > 
> >