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

[Christian Mauderer]

Am 12.10.2017 um 19:42 schrieb Chris Johns:
> 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 = -O2 -g
>>>> -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.

OK. It felt a little bit like a hack to me (using an environment
variable during configure) but if you think it would be an improvement,
I wouldn't offend.

> 
>> 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.

Like you noted, I'm not sure too. It just seems that every BSP sets
them. I'm also not sure why some BSPs have additional options and
whether they are necessary. So for me it would currently be only
possible to leave all other options untouched.

> 
>> 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 ?= -O0 -g
>>   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 ?= -O0
>    CFLAGS_DEBUG_V ?= -g
>    CFLAGS_OPTIMIZE_V += $(CFLAGS_DEBUG_V) -ffunction-sections -fdata-sections
> 
> Is that too much?

It would add two options instead of one. Maybe we should just put the -g
to the default options in every BSP. It only increases the size of the
binaries on the development host. If it is necessary to have some very
small binaries, it is still possible to strip them. So I can't think of
a case where -g hurts someone. So I would rather use a

  CFLAGS_OPTIMIZE_V ?= -O0
  CFLAGS_OPTIMIZE_V += -g -ffunction-sections -fdata-sections

> 
> It would make documenting what this does simpler.

To be honest: I wouldn't be sure where the documentation should go. Do
we have some guide about how to configure and compile a BSP?

Regards

Christian

-- 
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.