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 > > ----------------------------------------------- > > > > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev