• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 67 subscribers
  • Views 2315 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 103455
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

gcc emitting wrong floating point instructions?

Torsten Robitzki

Hi there, I'm currently facing the problem, that an example as simple as

volatile float sum;
extern "C" int _start()
{
    float a = 1.0;
    double d = 2.2;
    sum = a + d;
    for(;;);

}

is causing problems.

The compiler is invoked with -mcpu=cortex-m0 -mabi=aapcs -mthumb -msoft-float -mfloat-abi=soft (and many othere switches). The generated assembler looks like this:

extern "C" int _start()
...
d6:	f000 fb33 	bl	740 <____aeabi_f2d_from_thumb>
...
00000740 <____aeabi_f2d_from_thumb>:
740:	4778      	bx	pc
742:	46c0      	nop			; (mov r8, r8)
744:	eaffffa3 	b	5d8 <__aeabi_f2d>

When I step through this using a JLink-Debug, the last instructions are:

000000D6:  00 F0 33 FB        BL      #+0x666
J-Link>s
00000740:  78 47              BX      PC

Then the cpu is cycling in the HardFault handler. To me it looks like, the gcc is emitting wrong code, right? But how can I fix it? We use the binaries offered by ARM:

$ arm-none-eabi-gcc -v
...
gcc version 4.8.4 20140526 (release) [ARM/embedded-4_8-branch revision 211358] (GNU Tools for ARM Embedded Processors)

The target device is a 51422.

Any help, idea, pointers are highly appreciated.

Kind regards, Torsten

Parents
  • 0

    Well the code is correct, sort of, and I don't know whether it's being generated by gcc or linked in from a library, probably generated. That 'bx pc' jumps to the PC+4 and switches to ARM mode, which is why you're ending up in the hard fault handler, in Thumb mode that's not allowed. There's a clue in the function name, __aeabi_f2d_from_thumb, that looks like a thunk to the f2d (I guess that's float division) library function 'from thumb'.

    So it seems to me the compiler thinks it should be using an ARM FP library which it's linked in, and has generated a correct call into ARM code for it, but you're on a Thumb device.

    Possibilities, there's another flag on the command line confusing it, perhaps try to compile that line by hand with different flags to see what you get. I see you're using 4.8.4 of gcc, have you tried 4.8.3, may be a regression.

Reply
  • 0

    Well the code is correct, sort of, and I don't know whether it's being generated by gcc or linked in from a library, probably generated. That 'bx pc' jumps to the PC+4 and switches to ARM mode, which is why you're ending up in the hard fault handler, in Thumb mode that's not allowed. There's a clue in the function name, __aeabi_f2d_from_thumb, that looks like a thunk to the f2d (I guess that's float division) library function 'from thumb'.

    So it seems to me the compiler thinks it should be using an ARM FP library which it's linked in, and has generated a correct call into ARM code for it, but you're on a Thumb device.

    Possibilities, there's another flag on the command line confusing it, perhaps try to compile that line by hand with different flags to see what you get. I see you're using 4.8.4 of gcc, have you tried 4.8.3, may be a regression.

Children
Related