[rtems commit] bsp/atsam: Allow to change optimization settings.

Chris Johns chrisj at rtems.org
Thu Oct 12 17:42:52 UTC 2017

On 12/10/17 9:36 am, Christian Mauderer wrote:
> Am 12.10.2017 um 18:06 schrieb Chris Johns:
>> On 12/10/17 12:00 am, Sebastian Huber wrote:
>>> @@ -4,7 +4,6 @@ RTEMS_CPU = arm
>>>  CPU_CFLAGS = -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard
>>> -CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections
>>> +CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections
>> This is a really nice change. Should all the BSP's be changed?
>> I see a 104 instances in the code and the change could be scripted.
>> Being inconsistent on something that could be consistent across all BSPs is
>> confusing to all users.
> the change is just similar to some other BSPs (like or1k or realview).

It is a great idea and I think useful for all users of RTEMS.

> If we want to offer something like that for all BSPs, it might would be
> a better idea to split the flags up (what I haven't done here). 

Yes it might pay to split them up.

> I think the -ffunction-sections -fdata-sections is allways necessary?

I am not sure which archs can use the function and data sections. It is the `?=`
I like.

> Some BSPs
> have some other options too like an additional -fomit-frame-pointer in
> rbtx4925 or a -mmultiple in mcp750. So if a user would want to use that
> environment variable to change optimization, the value wouldn't be
> consistent across BSPs.

Ah ok.

> A consistent solution could be to split it up like in or1k:
>   CFLAGS_OPTIMIZE_V += -ffunction-sections -fdata-sections
> The general optimization could be overwritten with CFLAGS_OPTIMIZE_V and
> the BSP-specific parts would be added in the second line.
> What do you think?

The or1k solution looks good. What if we did something like:

   CFLAGS_OPTIMIZE_V += $(CFLAGS_DEBUG_V) -ffunction-sections -fdata-sections

Is that too much?

It would make documenting what this does simpler.


More information about the devel mailing list