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.


./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.

I really would like to but there is no gcc 4.4.4 in stable/2009. And .dev currently fails to build in virtual/kernel.

cp: cannot stat `/home/oe/build/out.dev/work/n1200-angstrom-linux/linux-n1200-2.6.27-rc9+git-r3/linux-2.6.27-foonas-git//home/oe/build/out.dev/work/n1200-angstrom-linux/linux-n1200-2.6.27-rc9+git-r3/linux-2.6.27-foonas-git/arch/powerpc/boot/cuImage.thecus_n1200': No such file or directory
ERROR: Function do_deploy failed

I think I have a buildable .dev state at work and will retry 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

Reply via email to