toolchain.inc: Fix addition of CFLAGS

Toolchain variables (CFLAGS, INCLUDES, etc.) defined by
create_class_compiler can be updated in toolchain.inc only after call
to create_class_compiler is performed. Here, CFLAGS_nonx86 was added
to CFLAGS_arm64 before create_class_compiler and hence the flags did
not show up during compilation.

BUG=None
BRANCH=None
TEST=Checked that dummy unused function does not show up in
ramstage.elf for ryu.

Change-Id: Ia152aaeef6d68f31eddda88506ee6630749f9dbb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/239245
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242161
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
This commit is contained in:
Furquan Shaikh 2015-01-07 12:42:53 -08:00 committed by ChromeOS Commit Bot
commit dde230b25b

View file

@ -34,25 +34,6 @@ ARCHDIR-arm64 := arm64
ARCHDIR-x86_32 := x86
ARCHDIR-mipsel := mips
# About -Wstack-usage: if you arrived here via grep, you were probably trying to
# do something naughty that could've caused boards with 2K stack size to have a
# very bad time somewhere down the road. Since stack overflows are both very
# dangerous and almost impossible to prevent, we're drawing the line at 1.5K
# for a single function frame (with the assumption that you hopefully don't
# chain more than one of that size together). Buffers larger than that should
# be allocated in the BSS (use MAYBE_STATIC if you need to share code with
# __PRE_RAM__ x86). Since GCCs detection of dynamic array bounds unfortunately
# seems to be very basic, you'll sometimes have to use a static upper bound
# for the size and an assert() to make sure it's honored (see gpio_base3_value()
# for an example). (If you absolutely need a larger stack frame and are 100%
# sure it cannot cause problems, you can whitelist it with #pragma diagnostic.)
CFLAGS_nonx86 := -ffunction-sections -fdata-sections -Wstack-usage=1536
CFLAGS_arm := $(CFLAGS_nonx86) -mno-unaligned-access
CFLAGS_arm64 := $(CFLAGS_nonx86)
CFLAGS_mipsel := $(CFLAGS_nonx86) -mips32r2 -G 0
toolchain_to_dir = \
$(foreach arch,$(ARCH_SUPPORTED),\
$(eval INCLUDES_$(ARCH_TO_TOOLCHAIN_$(arch)) = \
@ -117,6 +98,31 @@ init_stages = \
$(eval $(call create_class_compiler,x86_32,i386))
$(eval $(call create_class_compiler,arm64,aarch64))
# IMPORTANT: Toolchain variables (CFLAGS_, INCLUDES_) defined by
# create_class_compiler can be updated only after call to create_class_compiler
# is performed. DO NOT move the CFLAGS_* assignment before above call to
# create_class_compiler.
# About -Wstack-usage: if you arrived here via grep, you were probably trying to
# do something naughty that could've caused boards with 2K stack size to have a
# very bad time somewhere down the road. Since stack overflows are both very
# dangerous and almost impossible to prevent, we're drawing the line at 1.5K
# for a single function frame (with the assumption that you hopefully don't
# chain more than one of that size together). Buffers larger than that should
# be allocated in the BSS (use MAYBE_STATIC if you need to share code with
# __PRE_RAM__ x86). Since GCCs detection of dynamic array bounds unfortunately
# seems to be very basic, you'll sometimes have to use a static upper bound
# for the size and an assert() to make sure it's honored (see gpio_base3_value()
# for an example). (If you absolutely need a larger stack frame and are 100%
# sure it cannot cause problems, you can whitelist it with #pragma diagnostic.)
CFLAGS_nonx86 += -ffunction-sections -fdata-sections -Wstack-usage=1536
CFLAGS_arm += $(CFLAGS_nonx86) -mno-unaligned-access
CFLAGS_arm64 += $(CFLAGS_nonx86)
CFLAGS_mipsel += $(CFLAGS_nonx86) -mips32r2 -G 0
$(eval $(call toolchain_to_dir))
$(eval $(call init_stages))