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

[Chris Johns]

On 12/10/17 11:50 pm, Christian Mauderer wrote:
> 
> 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.
> 

Given the build system we have this seems to be the best of a poor set of
options we have. It is preferable over asking users to edit config files.

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

Joel let me know yesterday all bsps should support the options.

> I'm also not sure why some BSPs have additional options and
> whether they are necessary. 

That is just how the BSPs are.

> So for me it would currently be only
> possible to leave all other options untouched.

Agreed.

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

I agree. I only split them because there is more than the `-g` option for debug
info, there are other variants and some times debuggers need something different.

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

I agree.

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

Is suppose the RTEMS User Manual. It could be part of the instructions on building.

Chris