[rtems commit] bsp/atsam: Allow to change optimization settings.
chrisj at rtems.org
Fri Oct 13 13:58:02 UTC 2017
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
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.
>>> 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.
> 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.
More information about the devel