Changing compilation options for BSP building

John Pickwick john.pickwick at free.fr
Sun Feb 12 20:11:29 UTC 2006


Thanks Bruce,
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,
John

----- 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,
> Bruce
>
> 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 
>>instruction,
>>* 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 
>>compilation.
>>
>>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 :
>>-msoft-float option
>>    implies (assumption based on comments in sparc.h)
>>_SOFT_FLOAT in sparc.h
>>    implies
>>SPARC_HAS_FPU == 0 in sparc.h
>>    implies
>>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 ?
>>
>>John.
>>
>>
>>
>>----- 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
>>>LEON hardware.
>>>
>>>Jiri.
>>>
>>>
>>>John Pickwick wrote:
>>>>Hi to all,
>>>>
>>>>What should I do to change the compilation options used during my bsp
>>>>buid ?
>>>>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'
>>>>error).
>>>>
>>>>Thanks for help,
>>>>John.
>>>>.
>>
>>
>
> 




More information about the users mailing list