Changes between Version 19 and Version 20 of TBR/UserManual/Floating_Point_Support

Timestamp:

02/09/16 16:45:39 (8 years ago)

Author:

Thanassis Tsiodras

Comment:

--

TBR/UserManual/Floating_Point_Support

@@ -162 +162 @@
 
 Given the current state of the GCC compilers, this means user ISR handlers need to be compiled with {{{-msoft-float</code>, so that the compiler does not emit any FPU instructions or use FPU registers as part of the handler.
+
+= An update (Feb/2016) on using Leon2/3 FPU under RTEMS4.11 =
+
+Executive summary: if you are targeting native FPU usage, consider patching leon2.cfg/leon3.cfg to remove the "-msoft-float".
+
+Caveat: I am only an RTEMS user, not a dev ; so you'll need to perform your own tests if you do this. Currently (Feb/2016) opinions on the proper way to do FPU support on Leons are split on the RTEMS list. You can follow the lively discussion that sprang from the relevant bug report here: https://lists.rtems.org/pipermail/users/2016-February/029782.html
+
+Basically, the report includes a detailed step-by-step guide where the instructions from the RTEMS documentation are religiously followed, to build the cross compiler and the current head of the sparc/rtems-4.11 branch. It then proceeds to compile the RTEMS samples, and sees them working fine for non-FPU compilation - downloading them to the boards and seeing them work perfectly. However, when the samples - including the hello world RTEMS sample - are compiled with "-mhard-float" (or simply without "-msoft-float", which does the same thing) segfaults happen inside newlib. 
+
+No-one came up with an explanation on why this happens - my prevailing theory is that the *sizeof* of some structures is in fact influenced by the use or absence of "-msoft-float" - leading to inconsistent memory allocations, with eventual corruptions leading to the crash in newlib. The crash disappeared when I followed Sebastian Huber's advice, and compiled the Leon3/Leon3 BSPs without "-msoft-float" - basically, what I saw is that if your app is going to use FPU emulation, compile your BSPs in the same way ; and if your app needs native FPU, compile your BSPs with native FPU support.
+
+Jiri Gaisler raised concerns in the list discussion about older versions of GCC emitting FPU instructions for integer work ; this would break the kernel (since FPU context switching would lose/overwrite values). There's a pending request to Daniel Hellström for a few lines of code that used to trigger the compiler bug, which would be tried now with the latest version of the compiler to see if the bug is still there. The safe approach is take care to objdump your code and make sure there's no FPU register access in the kernel.