On Sat, 2010-01-23 at 13:39 -0500, Daniel Clark wrote: > Does anyone know canonically if the system can have instability > because *any* executable program is compiled without the loongson2f > as/binutils fixes? > > The site http://dev.lemote.com/code/firefox-3.7-loongson-jit says: > > "Recommend building with Lemote's tool-chain > http://dev.lemote.com/files/binary/toolchain/gcc4ls2f.tar to avoid a > potential bug http://sourceware.org/ml/binutils/2009-11/msg00387.html." > > I was under the impression that only the kernel, linux had to be > compiled with the loongson2f as/binutils fixes to avoid system lockups > due to silicon-level loongson2f bugs. >
As I have said in http://sourceware.org/ml/binutils/2009-11/msg00387.html, only -mfix-loongson2f-nop is needed for user-space applications. > If this is wrong then I feel gNewSense (a Debian-based GNU/Linux > distribution) might as well spend the time to make a n32 ABI / > loongson2f / loongson2f as bug fixes variant of gNewSense now, rather > then waiting on the Debian work in that area [1]. Yes, It's better to compile all of the applications with -mfix-loongson2f-nop. The n32 porting is really a very good message to us, which may bring us with better performance about +30%(?). Seems the best options combination is: -O3 -march=loongson2f -mabi=n32. > > Also, I have been told recently produced loongson2f chips have fixed > these bugs, so not everyone may see them. Does anyone know how to tell > if one has a version of the loongson2f chip with the bug that requires > the binutils patches? > I'm not sure which exact revision of loongson2f have fixed these bugs, but we may distinguish them via the revision number in the register of processor(Processor Revision Identifier (PRID) Register). And since the workaround method(repaces the nop instruction by another dummy instruction: "or at,at,zero") used by -mfix-loongson2f-nop have no big side effect(some testing is needed to verify it), so, it's better to enable it for all of the loongson2f processors. Regards, Wu Zhangjin _______________________________________________ gNewSense-dev mailing list gNewSense-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/gnewsense-dev