Linux C++ ARM-Cross-Compiler floor function bug?

Question

The following sample application is supposed to floor an integer value:

#include <iostream>
#include <math.h>

int Round(double val)
{
    return val + 0.5;
}

double Round2(double val)
{
    return floor(val + 0.5);
}

int main() {
    double val1 = 16.75;
    cout << "Round 16.75: " << Round(val1) << endl;
    cout << "Round 21.60: " << Round2(21.60) << endl;
    cout << "Round 5.50: " << Round(5.50) << endl;
    cout << "Round 5.40: " << Round2(5.40) << endl;
}

On my desktop pc both function are working correct.

If I cross-compile it for my raspberry with the arm-gnueabi-toolchain (v4.7.2) and copy the compiled file on my raspberry to execute it, the function that uses the floor function always returns zero.

If I compile the application on my raspberry it works fine.

Is this a bug or am I doing something wrong?

UPDATE:

arm-linux-gnueabi-readelf -h -A stamp 
    ELF Header:
      Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
      Class:                             ELF32
      Data:                              2's complement, little endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - System V
      ABI Version:                       0
      Type:                              EXEC (Executable file)
      Machine:                           ARM
      Version:                           0x1
      Entry point address:               0x8908
      Start of program headers:          52 (bytes into file)
      Start of section headers:          4852 (bytes into file)
      Flags:                             0x5000002, has entry point, Version5 EABI
      Size of this header:               52 (bytes)
      Size of program headers:           32 (bytes)
      Number of program headers:         8
      Size of section headers:           40 (bytes)
      Number of section headers:         32
      Section header string table index: 29
    Attribute Section: aeabi
    File Attributes
      Tag_CPU_name: "4T"
      Tag_CPU_arch: v4T
      Tag_ARM_ISA_use: Yes
      Tag_THUMB_ISA_use: Thumb-1
      Tag_ABI_PCS_wchar_t: 4
      Tag_ABI_FP_denormal: Needed
      Tag_ABI_FP_exceptions: Needed
      Tag_ABI_FP_number_model: IEEE 754
      Tag_ABI_align_needed: 8-byte
      Tag_ABI_align_preserved: 8-byte, except leaf SP
      Tag_ABI_enum_size: int
      Tag_DIV_use: Not allowed

Update2 It's not just the problem with double. When I try to return float I get only zeros, too.

Maybe you have floating-point support disabled? Not uncommon on systems with limited resources, since FP is computationally heavy. — , Jul 17 '13 at 14:26
The [Rpi-FAQ](http://www.raspbian.org/RaspbianFAQ) says that the `wheezy` image uses `hardware floating point`. So i guess, its enabled? — baam, Jul 17 '13 at 14:31
The **PC** compile may grab the wrong headers and/or some libraries that differ from the target. — artless noise, Jul 17 '13 at 14:32
Doesn't mean that the standard LIBRARY has FP library that contains "meaningful code". Have a look at the generated binary. — Mats Petersson, Jul 17 '13 at 14:32
The __PC__ is a debian system. how can i look at the generated binary and see whether its enabled or not? — baam, Jul 17 '13 at 14:36
On **debian**, you can install a 'multi-arch' binutils and dump **ARM** assembler. Alternatively, your tools (where arm-gnueabi-toolchain is) should have `arm-none-gnueabi-objdump` or something like that. — artless noise, Jul 17 '13 at 17:51
The toolchain provides `arm-linux-gnueabi-objdump`. What am I looking for? there a lot of options with a lot of output. with the `-x` option I get also this: `private flags = 5000002: [Version5 EABI] [has entry point]` — baam, Jul 18 '13 at 06:19
take a look in the startpost. i added the output from `arm-linux-gnueabi-readelf --file-header --arch-specific` — baam, Jul 18 '13 at 06:32
You **PC** compiler is not recognizing the CPU and has compiled with *ARMv4* ISA. Your CPU supports *ARMv6*. Use the option `-mcpu=arm1176jzf-s` to compile the code. On the Raspberry device, the compiler can ID the cpu and uses that naturally. — artless noise, Jul 18 '13 at 14:31
That solved the problem. If you add this as a answer I accept it. Thanks! — baam, Jul 19 '13 at 07:20

score 0 · Answer 1 · edited May 23 '17 at 10:32

0

Maby the crosscompiler is not linking to the correct float ABI try compiling with -mfloat-abi=hard . see http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

EDIT: In this thread is some more specific information about building a good toolset for cross compiling for the raspberrypi: Cross-compilation for Raspberry Pi in GCC. Where to start? maby the links there can help you more.

edited May 23 '17 at 10:32

Community

1
1

answered Jul 17 '13 at 15:06

hetepeperfan

4,292
1
29
47

If I try this i get the following error: `/usr/lib/gcc/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/bin/ld: error: /tmp/ccWZ4jKt.o uses VFP register arguments, stamp does not` `/usr/lib/gcc/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/bin/ld: failed to merge target specific data of file /tmp/ccWZ4jKt.o` `collect2: error: ld returned 1 exit status` – baam Jul 18 '13 at 06:26
1

@baam I added an extra link to find information about crosscompiling for the raspberrypi hopefully you find more usefull information there. – hetepeperfan Jul 18 '13 at 08:33

Linux C++ ARM-Cross-Compiler floor function bug?

1 Answers1