help understanding a gcc compilation issue

[Gabi Voiculescu <boy3dfx2@yahoo.com>]

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