erc32 wrong compilation flags for initial task with fpu?

[Jiri Gaisler]

We have been through this many times, please see my earlier posts
on this matter. In principle, the kernel should always be compiled
with -msoft-float to avoid gcc from using float registers for
integer operations (yes, it can do that). The application can
be compiled with our without -msoft-float depending on if an
FPU exists in the system. To enable FPU support, the RTEMS_FLOATING_POINT
attribute should be set on FPU tasks if -msoft-float
has NOT been use on the application. If -msoft-float has been used,
the RTEMS_FLOATING_POINT should never be set.

An interesting failure case is when gcc schedules an FPU instruction
in a part of your application which is executed by an integer-only task
(i.e. no RTEMS_FLOATING_POINT attribute). The task will then crash with
an FPU disable trap, potentially killing your satellite ...
The only way around this is to either set RTEMS_FLOATING_POINT on all
tasks, or none.

Jiri.

Joel Sherrill wrote:
> Aleix Conchillo Flaqué wrote:
>> On Thu, Mar 27, 2008 at 2:08 PM, Joel Sherrill
>> <joel.sherrill at oarcorp.com> wrote:
>>   
>>>  Did you every configure the attributes of the initialization
>>>  task to be floating point or where you just getting lucky?
>>>
>>>  #define CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_FLOATING_POINT
>>>
>>>     
>> For sure.
>>
>> #define CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_LOCAL | RTEMS_FLOATING_POINT
>>
>> As I said, with 4.6.1, 4.6.2 and 4.6.4 the application worked fine.
>> After the SPARC update in 4.6.5 it just failed at the initialisation
>> task (which uses fpu). Removing the -msoft-float from 4.6.6 solved the
>> problem.
>>
>> Yesterday I looked at the patch for the whole afternoon and I did not
>> see anything else that could affect, but I am not an expert in RTEMS
>> internals, so probably I am missing something.
>>   
> Look at cpukit/score/src/threadhandler.c and make sure
> the thread wrapper code is actually initializing the FP
> context correctly the first time to enable it.
> 
> Jiri can comment directly but I recall that the SPARC port
> assumes RTEMS itself is always soft-float but the application
> can be compiled with hardware FP enabled and things will
> just work. 
>> Aleix
>>   
> 
>