On Tue, May 25, 2010 at 8:15 AM, Vitus Jensen <[email protected]> wrote: > On Mon, 24 May 2010, Khem Raj wrote: >> >> On (24/05/10 18:36), Vitus Jensen wrote: > > >>> Hmm, I'm using angstrom with glibc. And I'm testing on the real >>> device and saw that -mhard-float is implied by mcpu=603e. Using the >>> FPU would certainly explain differences between qemu and the real >>> thing. But __floatdidf is hard to understand, all macro. Is it >>> really using the FPU? >> >> Yeah that could be something to look at. In general if gcc is using >> fp instruction to schedule then it might be using them. >> >> You should try to find which libgcc is it linking to when using g++ >> and gcc. It could be that its linking in two different libgcc versions >> >> secondly try to compile program statically and then run it. > > > Using -static-libgcc and -shared-libgcc was interesting, it just affects the > gcc support code. static is default for C, shared for C++ and forcing > static for C++ produced correct output. When comparing implementations: > > * static uses inline fpu code, source > work/i686-ppc603e-sdk-angstrom-linux/gcc-cross-sdk-4.4.4-r2.1/gcc-4.4.4/gcc/libgcc2.c > > * shared calls into libgcc_s.so.1 which uses software, excerpt: > Dump of assembler code for function __floatdidf: > => 0x0fe12878 <+0>: stwu r1,-32(r1) > 0x0fe1287c <+4>: mflr r0 > 0x0fe12880 <+8>: stmw r26,8(r1) > 0x0fe12884 <+12>: mr r27,r4 > 0x0fe12888 <+16>: mr r26,r3 > 0x0fe1288c <+20>: srawi r9,r26,31 > 0x0fe12890 <+24>: srawi r10,r26,0 > 0x0fe12894 <+28>: stw r0,36(r1) > 0x0fe12898 <+32>: mr r3,r10 > 0x0fe1289c <+36>: bl 0xfe31244 <__floats...@plt> > 0x0fe128a0 <+40>: lis r5,16880 > > > [STABLE/2009] There are 2 libgcc_s.so.1 versions in TMPDIR/cross, the bigger > ./ppc603e/powerpc-angstrom-linux/lib/nof/libgcc_s.so.1 matches the installed > version,
thats the problem if one copies the smaller version (uses fpu code) to target:/lib/ > the results of -shared-libgcc applications are OK. > > So, hard-fpu and soft-fpu are incompatible? The incorrect version matches > (strip; cmp -l) several paths in TMPDIR/work: its more the calling convention. > > ./ppc603e-angstrom-linux/gcc-4.2.4-r3/image/lib/libgcc_s.so.1 > ./ppc603e-angstrom-linux/gcc-4.2.4-r3/gcc-4.2.4/build.powerpc-angstrom-linux.powerpc-angstrom-linux/gcc/nof/libgcc_s.so.1 > ./ppc603e-angstrom-linux/gcc-cross-4.2.4-r5/install/libgcc/lib/libgcc_s.so.1 > ./ppc603e-angstrom-linux/gcc-cross-4.2.4-r5/image/lib/libgcc_s.so.1 > ./ppc603e-angstrom-linux/gcc-cross-4.2.4-r5/staging-pkg/cross/powerpc-angstrom-linux/lib/nof/libgcc_s.so.1 > ./ppc603e-angstrom-linux/gcc-cross-4.2.4-r5/gcc-4.2.4/build.i686-linux.powerpc-angstrom-linux/gcc/nof/libgcc_s.so.1 > > But there are 4 other smaller versions of that library, the good one coming > from gcc-4.2.4. or gcc-cross-4.2.4. Which recipes decides which version to > copy into the image? For now it seems enough to copy a fpu-version by hand > into the image but this is hardly an universal solution. actually it should have packaged the fpu version into /lib on target but its a bug that it instead copied nof version. I think I touched this area and saw this problem in past. Can you try gcc 4.4.4 and see if the problem still happens there. > > Vitus > > -- > Vitus Jensen, Hannover, Germany, Universe (current) > pgp public key available from keyservers > > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
