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

[Christian Mauderer]

Am 13.10.2017 um 15:58 schrieb 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.

Hello Chris,

I took a look at the necessary changes. Most of it is quite straight
forward.

Regarding the CFLAGS_DEBUG_V: I can see that a variable with that name
is set in a few files:

   c/src/make/compilers/gcc-target-default.cfg
   c/src/lib/libbsp/powerpc/beatnik/make/custom/beatnik.cfg

But it seems that it isn't really used anywhere. Is that some reserved
name that is used by autotools? It seems that it is set to the same
value as CFLAGS_OPTIMIZE_V in the cases where I found it.

The description in the c/src/make/README reads more like it should be
only set to the -g like in your suggested example. Do you see any reason
why it could be problematic to use the CFLAGS_DEBUG_V and set it to only
'-g' (or '-ggdb3' in the lpc1768_mbed bsp and '-ggdb' in the
tms570ls3137 bsp)?

Regards

Christian

> 
>> 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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>