arm, arm64, mips: Add rough static stack size checks with -Wstack-usage

We've seen an increasing need to reduce stack sizes more and more for
space reasons, and it's always guesswork because no one has a good idea
how little is too litte. We now have boards with 3K and 2K stacks, and
old pieces of common code often allocate large temporary buffers that
would lead to very dangerous and hard to detect bugs when someone
eventually tries to use them on one of those.

This patch tries improve this situation at least a bit by declaring 2K
as the minimum stack size all of coreboot code should work with. It
checks all function frames with -Wstack-usage=1536 to make sure we don't
allocate more than 1.5K in a single buffer. This is of course not a
perfect test, but it should catch the most common situation of declaring
a single, large buffer in some close-to-leaf function (with the
assumption that 0.5K is hopefully enough for all the "normal" functions
above that).

Change one example where we were a bit overzealous and put a 1K buffer
into BSS back to stack allocation, since it actually conforms to this
new assumption and frees up another kilobyte of that highly sought-after
verstage space. Not touching x86 with any of this since it's lack of
__PRE_RAM__ BSS often requires it to allocate way more on the stack than
would usually be considered sane.

BRANCH=veyron
BUG=None
TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky,
made sure they still build as well as before and don't show any stack
usage warnings.

Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f
Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236978
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9729
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>

1 files changed, 18 insertions, 0 deletions

diff --git a/toolchain.inc b/toolchain.inc
index 89bc55c6bbc1..eea0560328cc 100644
--- a/toolchain.inc
+++ b/toolchain.inc
@@ -74,6 +74,24 @@ CFLAGS_riscv	+= -ffunction-sections -fdata-sections
 
 CFLAGS_x86_64   += -mcmodel=large -mno-red-zone
 
+# Some boards only provide 2K stacks, so storing lots of data there leads to
+# problems. Since C rules don't allow us to statically determine the maximum
+# stack use, we use 1.5K as heuristic, assuming that we typically have lots
+# of tiny stack frames and the odd large one.
+#
+# Store larger buffers in BSS, use MAYBE_STATIC to share code with __PRE_RAM__
+# on 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_arm	+= -Wstack-usage=1536
+CFLAGS_arm64	+= -Wstack-usage=1536
+CFLAGS_mips	+= -Wstack-usage=1536
+CFLAGS_riscv	+= -Wstack-usage=1536
+
 toolchain_to_dir = \
 	$(foreach arch,$(ARCH_SUPPORTED),\
 	$(eval CPPFLAGS_$(arch) += \