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

Timestamp:

02/09/16 16:48:19 (8 years ago)

Author:

Thanassis Tsiodras

Comment:

--

TBR/UserManual/Floating_Point_Support

@@ -171 +171 @@
 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.
+No-one came up with an explanation on why this happens - the 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 we followed Sebastian Huber's advice, and compiled the Leon3/Leon3 BSPs without "-msoft-float" - basically, what we saw was that if your app is going to use FPU emulation, you need to compile your BSPs in the same way ; and if your app needs native FPU, again, you need to 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.
+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 this compiler bug - which we could try now with the latest version of the compiler and see if the bug is still there. The safe approach is to take care to objdump your code - and make sure there's no FPU register accesses in the kernel.