[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
erc32 wrong compilation flags for initial task with fpu?
- Date: Thu, 27 Mar 2008 17:48:08 +0100
- From: jiri at gaisler.com (Jiri Gaisler)
- Subject: erc32 wrong compilation flags for initial task with fpu?
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.
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
>> 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.