erc32 wrong compilation flags for initial task with fpu?

[Jiri Gaisler]

Aleix Conchillo Flaqué wrote:
> Hi,
> 
> I understand what you say and already read your posts. The problem is
> that the -msoft-float is now set by default in the ERC32 bsp so it
> affects RTEMS itself. May be I am missing something but checking
> _Thread_Handler I see:

Well, all bsps should use -msoft-float to compile the kernel itself,
that is what I tried to explain to you. The #define SPARC_HAS_FPU 1
should always also be set, so that the FPU context-save code always
is present. If the application does not use RTEMS_FLOATING_POINT,
it will never be called. It might be that your version of RTEMS
does not set #define SPARC_HAS_FPU 1. This is an error. I believe
it comes from a patch I submitted, but which was only merged
partially into one particular version of RTEMS, omitting this #define.

What I would really worry about is what will happen if the
kernel is compiled without -msoft-float and gcc schedules an FPU
op somewhere in the kernel code. You will then potentially corrupt
the FPU context ...

Jiri.

> 
> #if ( CPU_HARDWARE_FP == TRUE ) || ( CPU_SOFTWARE_FP == TRUE )
> #if ( CPU_USE_DEFERRED_FP_SWITCH == TRUE )
>   if ( (executing->fp_context != NULL) && !_Thread_Is_allocated_fp(
> executing ) ) {
>     if ( _Thread_Allocated_fp != NULL )
>       _Context_Save_fp( &_Thread_Allocated_fp->fp_context );
>     _Thread_Allocated_fp = executing;
>   }
> #endif
> #endif
> 
> Which will never execute as the -msoft-float flag is set by default.
> 
> #if ( SPARC_HAS_FPU == 1 )
> #define CPU_HARDWARE_FP     TRUE
> #else
> #define CPU_HARDWARE_FP     FALSE
> #endif
> 
> and
> 
> #if defined(_SOFT_FLOAT)
> #define SPARC_HAS_FPU 0
> #else
> #define SPARC_HAS_FPU 1
> #endif
> 
> _SOFT_FLOAT is defined by -msoft-float.+
> 
> Aleix
> 
> 
> On Thu, Mar 27, 2008 at 5:48 PM, Jiri Gaisler <jiri at gaisler.com> wrote:
>>  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.
>>
>>
> 
>