Hello.
Sorry about the intelligibility of this email but it is pretty late over here.
I am a newbie when it comes to gcc abi. I usually write my code in C.
I found a weird issue when porting a piece of software from a crostools gcc-3.4.4 based toolchain to a crostools based gcc-4.2.4 and I would like some help understanding it.
When running, the function llrint() using and returning 64 bit variables fails to call rint(), and instead calls itself!?!.
#include <stdio.h>
extern double rint(double x);
long long llrint(double x);
long long llrint(double x)
{
printf("%s,%d llrint entry\n", __func__, __LINE__); //-gabi 07/08/2009
return (long long) rint(x);
}
When calling llrint I see the print statement repeated forever, without calling rint() or returning from llrint().
The way I fixed my issue: I had to use local variables to store the result from rint:
#include <stdio.h>
extern double rint(double x);
long long llrint(double x);
long long llrint(double x)
{
double result;
long long temp;
result =rint(x);
temp =(long long) result;
printf("%s,%d llrint entry\n", __func__, __LINE__); //-gabi 07/08/2009
return (long long) rint(x);
}
I must say I am verifying this code as part of a ported libm over l4, for armv5te platform in the skyeye emulator.
The compiler has been obtained from the steps specified at: wiki.ok-labs.com:
To build such a cross compiler get the latest version of Crosstool 0.43 and apply the Crosstool EABI patch. Then build the toolchain with:
# sh demo-arm-softfloat.sh
If anybody knows if this issue comes from a known gcc behaviour I would appreciate a reply. I have attached the result of objdump-ing the compiled object, for each example code from above.
Hope to get some feedback,
Gabi Voiculescu
--------------------------------------------------------------------------
compilation command:
/opt/okl/Linux-i386/arm/gcc-4.2.4-glibc-2.7/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc --std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wmissing-declarations -Wredundant-decls -Wundef -Wpointer-arith -Wno-nonnull -Werror -march=armv5te -mtune=xscale -O2 -nostdlib -nostdinc -g -DARCH_ARM -DARCH_VER=5 -DMACHINE_GUMSTIX2 -DENDIAN_LITTLE -DWORDSIZE_32 -DARM_PID_RELOC=1 -DARM_SHARED_DOMAINS=1 -D__ARMv__=5 -D__ARMv5TE__ -DPLATFORM_PXA=1 -DSERIAL_FFUART=1 -DVIDEO_HACK=1 -DVIDEO2_HAC
K=1 -DUSE_MOV=1 -DUSE_LIBM=1 -DDEBUG_PRINT_EXCEPTION=1 -DIG_APP_CONFIG_PLAT_PXA=1 -DIG_DEBUG_PRINT=1 -DPXA_LCD_DRIVER=1 -DMAIN_MENU=1 -DENABLE_SKYEYE_DEBUGGING=1 -DCONFIG_VERBOSE_INIT=1 -DARM_PID_RELOC=1 -DARM_SHARED_DOMAINS=1 -D__ARMv__=5 -D__ARMv5TE__ -DPLATFORM_PXA=1 -DSERIAL_FFUART=1 -DVIDEO_HACK=1 -DVIDEO2_HACK=1 -DUSE_MOV=1 -DUSE_LIBM=1 -DDEBUG_PRINT_EXCEPTION=1 -DIG_APP_CONFIG_PLAT_PXA=1 -DIG_DEBUG_PRINT=1 -DPXA_LCD_DRIVER=1 -DMAIN_MENU=1 -DENABLE_SKYEYE_DEBUGGING=1 -DCONFIG_VERBOSE_INIT=1 -DKENGE_IGUANA -DKENGE_IGUANA -DKENGE_L4_ROOTSERVER -DTHREAD_SAFE -DMAX_ELF_SEGMENTS=1000 -DIGUANA_VERSION=20060101UL -DIGUANA_DEBUG=5 -DIG_DEBUG_PRINT -DCONFIG_TRACEBUFFER=1 -DIG_VERBOSE -DCONFIG_MAX_THREAD_BITS=10 -DCONFIG_SCHEDULE_INHERITANCE=1
-DCONFIG_EAS=1 -DCONFIG_ZONE=1 -DCONFIG_MEM_PROTECTED=1 -DCONFIG_MEMLOAD=1
-DCONFIG_REMOTE_MEMORY_COPY=1 -DCONFIG_USER_MUTEXES=1 -D__L4_ARCH__=arm -DL4_ARCH_ARM -DCONFIG_DEBUG=1 -Ibuild_demogb/iguana/include -Ibuild_demogb/iguana/object/libs_m/src -Ilibs/m/src libs/m/src/common/s_llrint.c -c -o build_demogb/iguana/object/libs_m/src/common/s_llrint.o
--------------------------------------------------------------------------
Original (non working/looping code objdump):
s_llrint.o.not.ok: file format elf32-littlearm
Disassembly of section .text:
00000000 <llrint>:
extern double rint(double x);
long long llrint(double x);
long long llrint(double x)
{
0: e92d4030 stmdb sp!, {r4, r5, lr}
printf("%s,%d llrint entry\n", __func__, __LINE__); //-gabi 07/08/2009 FIXME: remove rint statememt
4: e3a0200d mov r2, #13 ; 0xd
8: e1a04000 mov r4, r0
c: e1a05001 mov r5, r1
10: e24dd004 sub sp, sp, #4 ; 0x4
14: e59f1018 ldr r1, [pc, #24] ; 34 <.text+0x34>
18: e59f0018 ldr r0, [pc, #24] ; 38 <.text+0x38>
1c: ebfffffe bl 1c <llrint+0x1c>
#if 1 //-gabi 07/08/2009 Does this fix the call to rint problem? what is the cause of the rint
long long temp;
double result;
result = rint(x);
temp = (long long) result;
return temp;
#else
return (long long) rint(x);
20: e1a00004 mov r0, r4
24: e1a01005 mov r1, r5
#endif
}
28: e28dd004 add sp, sp, #4 ; 0x4
2c: e8bd4030 ldmia sp!, {r4, r5, lr}
30: eafffffe b 30 <llrint+0x30>
...
--------------------------------------------------------------------------
New (working code objdump):
s_llrint.o.ok: file format elf32-littlearm
Disassembly of section .text:
00000000 <llrint>:
extern double rint(double x);
long long llrint(double x);
long long llrint(double x)
{
0: e92d4030 stmdb sp!, {r4, r5, lr}
printf("%s,%d llrint entry\n", __func__, __LINE__); //-gabi 07/08/2009 FIXME: remove rint statememt
4: e3a0200d mov r2, #13 ; 0xd
8: e24dd004 sub sp, sp, #4 ; 0x4
c: e1a04000 mov r4, r0
10: e1a05001 mov r5, r1
14: e59f001c ldr r0, [pc, #28] ; 38 <.text+0x38>
18: e59f101c ldr r1, [pc, #28] ; 3c <.text+0x3c>
1c: ebfffffe bl 1c <llrint+0x1c>
#if 1 //-gabi 07/08/2009 Does this fix the call to rint problem? what is the cause of the rint
long long temp;
double result;
result = rint(x);
20: e1a00004 mov r0, r4
24: e1a01005 mov r1, r5
28: ebfffffe bl 28 <llrint+0x28>
2c: ebfffffe bl 2c <llrint+0x2c>
temp = (long long) result;
return temp;
#else
return (long long) rint(x);
#endif
}
30: e28dd004 add sp, sp, #4 ; 0x4
34: e8bd8030 ldmia sp!, {r4, r5, pc}
...
