Changing compilation options for BSP building
john.pickwick at free.fr
Sun Feb 12 20:11:29 UTC 2006
it now works fine.
My assumptions were right : the default setting in RTEMS 4.6.5 implies a
leon2 bsp compiled with the -msoft-float that seems to remove the associated
FPU context management in the routines that deal with threads.
After your suggested change and the recompilation of the bsp it works.
I understand Jiri's remark about a non-FPU leon2 and gcc implicit use of
float registers but I just can't see how it could work with a true hardware
fpu sparc without removing this flag.
Thanks to all,
----- Original Message -----
From: "Bruce Robinson" <brucer at pmccorp.com>
To: <rtems-users at rtems.com>
Cc: "John Pickwick" <john.pickwick at free.fr>
Sent: Tuesday, February 07, 2006 11:26 PM
Subject: Re: Changing compilation options for BSP building
> Hi John,
> I think the answer to your original question is that you need to edit the
> line :
> CPU_CFLAGS = -mcpu=cypress -msoft-float
> in the make/custom/leon2.cfg file.
> Best Regards,
> At 12:41 PM 2/7/2006, you wrote:
>>Thanks for your quick answer Jiri but I intend to try this because I have
>>the following problem :
>>* I've got an application with several tasks and just one floating point
>>task, I am targeting the AT697 from ATMEL that has a hardware FPU,
>>* of course, I created the FP task with FP attribute,
>>* when RTEMS switches to this task it does not restore the EF bit in PSR
>>which implies an "FP disabled" trap on the first floating point
>>* looking carefully at this problem under gdb I noticed that there was no
>>fp_context pointer field in the thread structure associated with this task
>>(this pointer is used to manage the fp_context in threadloadenv.c for
>>example). So I assumed that there was something wrong in my bsp
>>Therefore I found in thread.h that the fp_context field was enable/disable
>>by CPU_HARDWARE_FP define which in turn is conditionned by SPARC_HAS_FPU
>>define (in cpu.h) that is set or unset by _SOFT_FLOAT definition (in
>>sparc.h). In cpu.h the
>>CPU_SOFTWARE_FP is also set to FALSE.
>>As a consequence :
>> implies (assumption based on comments in sparc.h)
>>_SOFT_FLOAT in sparc.h
>>SPARC_HAS_FPU == 0 in sparc.h
>>CPU_HARDWARE_FP == FALSE in cpu.h
>>+ CPU_SOFTWARE_FP set to FALSE in cpu.h
>> which implies a disabled FP management in threadloadenv.c that is part
>> of the bsp.
>>Can you see what's wrong in my approach ?
>>----- Original Message ----- From: "Jiri Gaisler" <jiri at gaisler.com>
>>To: "RTEMS Users Mailing List" <rtems-users at rtems.com>
>>Sent: Tuesday, February 07, 2006 7:57 PM
>>Subject: Re: Changing compilation options for BSP building
>>>I would not recommend to remove the -msoft-float flag from
>>>CPU_FLAGS. There is not floating point operations done in
>>>the RTEMS kernel, hence you do not need to generate FPU
>>>instructions. If you remove the -msoft-float option, newer
>>>versions of gcc will use FPU registers for certain integer
>>>operations (!) and the kernel will not run on processors
>>>without an FPU. Hence, you do not gain anything by removing
>>>-msoft-float, except the opportunity of crashing on non-FPU
>>>John Pickwick wrote:
>>>>Hi to all,
>>>>What should I do to change the compilation options used during my bsp
>>>>I use the LEON2 / RTEMS 4.6.5 BSP and I'd like to replace the "CPU_FLAGS
>>>>= -mcpu=cypress -msoft-float" option used during the compilation to
>>>>suppress the soft-float setting.
>>>>I tried to set CC_FLAGS_TARGET or CPU_FLAGS directly on my configure
>>>>command line but it does not work (failed with an 'invalid build alias'
>>>>Thanks for help,
More information about the users