[oe] powerpc-g++ 4.2.4 problem casting long long to double
Khem Raj
raj.khem at gmail.com
Wed May 26 06:21:36 UTC 2010
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.
>>
>>>
>>> ./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.
OK. If I find time I will fix gcc 4.2.4 today
>
> Vitus
>
> --
> Vitus Jensen, Hannover, Germany, Universe (current)
> pgp public key available from keyservers
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
More information about the Openembedded-devel
mailing list