[oe] [STABLE] powerpc-g++ 4.2.4 problem casting long long to double
Vitus Jensen
vjensen at gmx.de
Mon Jun 7 19:23:09 UTC 2010
On Tue, 25 May 2010, Khem Raj wrote:
> On Tue, May 25, 2010 at 10:34 PM, Vitus Jensen <vjensen at gmx.de> wrote:
>> On Tue, 25 May 2010, Khem Raj wrote:
>>> On Tue, May 25, 2010 at 8:15 AM, Vitus Jensen <vjensen at gmx.de> 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 <__floatsidf at 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 <rpurdie at linux.intel.com>
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 <rpurdie at linux.intel.com>
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
More information about the Openembedded-devel
mailing list