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. > 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 ?= -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 make documenting what this does simpler. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
