Hi, I have been porting mozilla firefox to the SH4 platform. However, I have
run into some horrible floating point problems.
details:
gcc 4.1.0
glibc 2.3.6
(built using crosstool)
firefox 1.5.0.4
linux kernel 2.6.11
Running on an STB7100 with SH4-202 processor core (yes it does have an FPU).
I have been trying to make a small test case to illustrate the problem.. but I
cannot seem to manage it. It seems to be a prerequisite that I must have the
massive mozilla XPCOM shared libraries loaded or something.
Anyway, I manged to get my test code down to:
int main()
{
// printf("HELLO\n");
int x = 20;
float k = (float) x;
NS_InitXPCOM2(nsnull, nsnull, nsnull);
printf("THERE\n");
}
I also have debug prints inside NS_InitXPCOM2.
Basically if I leave the HELLO printf commented out, I do not see the debug in
NS_InitXPCOM2(). Instead I get a "floating point exception".
If I uncomment it I *do* see the debug (althought it later gets another FP
exception; this is the problem I'm really trying to solve).
If I comment out the call to NS_InitXPCOM2() it runs fine.
As far as I can make out it is NOT the NS_InitXPCOM2() itself which is failing
since it outputs my debug if I have the first printf uncommented.
If I add more trace elsewhere the problem sort of shifts about... it sounds
like some form of alignment problem to me.
Oh, I also tried creating my own shared library with an NS_InitXPCOM5() method
and calling that instead... that worked fine.
Can anyone advise a way I can try and work out what is going on to provide a
small example that _doesn't_ involve calling into mozilla XPCOM?
I can always provide the binaries and source if people want it.. but mozilla
is _huge_.
Oh, my test file was compiled with:
sh4-unknown-linux-gnu-gcc -o TestXPC.o -c -O0 \
-DMOZILLA_INTERNAL_API -DOSTYPE=\"Linux\" -DOSARCH=\"Linux\" \
-I../../../../dist/include/xpconnect \
-I../../../../dist/include/xpcom \
-I../../../../dist/include/js \
-I../../../../dist/include/nspr \
-fPIC \
/etv/branches/aminet130/scratch/amino-stb710x-mozilla/mozilla/js/src/xpconnect/tests/TestXPC.cpp
and linked with:
sh4-unknown-linux-gnu-gcc \
-o TestXPC \
TestXPC.o \
-L../../../../dist/bin -lxpcom -lxpcom_core \
-L../../../../dist/lib -lplds4 -lplc4 -lnspr4 \
-lpthread -ldl -ldl -lm -lsupc++
I've managed to track down the problem some more with GDB. Even though moving
calls about seems to move the issue about, it always seems to come from the
the following GCC function: udivsi3_i4
0x29ae4c50 <__udivsi3_i4+0>: mov #1,r1
0x29ae4c52 <__udivsi3_i4+2>: cmp/hi r1,r5
0x29ae4c54 <__udivsi3_i4+4>: bf 0x29ae4c74 <trivial>
0x29ae4c56 <__udivsi3_i4+6>: rotr r1
0x29ae4c58 <__udivsi3_i4+8>: xor r1,r4
0x29ae4c5a <__udivsi3_i4+10>: lds r4,fpul
0x29ae4c5c <__udivsi3_i4+12>: mova 0x29ae4c78 <L1>,r0
0x29ae4c5e <__udivsi3_i4+14>: fmov @r0+,fr5
0x29ae4c60 <__udivsi3_i4+16>: fmov @r0,fr4
0x29ae4c62 <__udivsi3_i4+18>: float fpul,fr0
0x29ae4c64 <__udivsi3_i4+20>: xor r1,r5
0x29ae4c66 <__udivsi3_i4+22>: lds r5,fpul
0x29ae4c68 <__udivsi3_i4+24>: float fpul,fr2
0x29ae4c6a <__udivsi3_i4+26>: fadd fr4,fr0
0x29ae4c6c <__udivsi3_i4+28>: fadd fr4,fr2
0x29ae4c6e <__udivsi3_i4+30>: fdiv fr2,fr0
0x29ae4c70 <__udivsi3_i4+32>: rts
0x29ae4c72 <__udivsi3_i4+34>: ftrc fr0,fpul
Specifically at:
#0 0x29ae4c6c in __udivsi3_i4 () from
mozilla/BUILDIT/js/src/xpconnect/tests/mnt/core/lib/libc.so.6
I'm afraid I cannot seem to get anything useful out of gdb (6.3) for the
floating point register contents. Although I have just noticed the libs are
nottbuild with debugging on. I'll rebuild the toolchain overnight and see if
anything more sensible comes out.
