[Fwd: [lemote] Re: Are -mfix-loongson2f-nop and -mfix-loongson2f-jump needed for userland programs?]
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
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
-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 .
Yes, It's better to compile all of the applications with
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.