On Tue, 25 May 2010, Khem Raj wrote:
On Tue, May 25, 2010 at 10:34 PM, Vitus Jensen <[email protected]> wrote:
On Tue, 25 May 2010, Khem Raj wrote:
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.
...
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.
The problem is the order / preference in which libs are copied into the
target dir. If one ports the following commit to the stable/2009 branch
the correct version remains on the target and resulting image should work:
commit 3fb59642b2b9afb7b8cd9769b53e24d85dc2f348
Author: Richard Purdie <[email protected]>
Date: Thu Dec 17 21:07:31 2009 +0000
gcc-pacpake-cross.inc: Clean up do_install function massively (from Poky)
Signed-off-by: Richard Purdie <[email protected]>
I need to clean TMPDIR, rebuild the image and test on the device. Will
post a patch if the result is good.
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
