summaryrefslogtreecommitdiff
path: root/src/lib/memmove.c
diff options
context:
space:
mode:
authorRonald G. Minnich <rminnich@chromium.org>2012-06-12 16:29:32 -0700
committerRonald G. Minnich <rminnich@gmail.com>2012-07-24 23:29:12 +0200
commit9764d4c690bbe4a54429e47a2094230da5fb88f5 (patch)
treee70c8afc9990fa34bf8cfd2df22370e90c231940 /src/lib/memmove.c
parent9842ad8ac5256d1800490c392b8cf7e4edd21ddc (diff)
Implement stack overflow checking for the BSP
Previous patches implemented stack overflow checking for the APs. This patch builds on the BSP stack poisoning patch to implement stack overflow checking for the BSP, and also prints out maximum stack usage. It reveals that our 32K stack is ridiculously oversized, especially now that the lzma decoder doesn't use a giant 16K on-stack array. Break the stack checking out into a separate function, which we will later use for the APs. CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8 To test failure, change the DEADBEEF stack poison value in c_start.S to something else. Then we should get an error like this: Stack overrun on BSP.Increase stack from current 32768 bytes CPU0: stack from 00180000 to 00188000:Lowest stack address 00180000 Separate the act of loading from the act of starting the payload. This allows us better error management and reporting of stack use. Now we see: CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8 Tested for both success and failure on Link. At the same time, feel free to carefully check my manipulation of _estack. Change-Id: Ibb09738b15ec6a5510ac81e45dd82756bfa5aac2 Signed-off-by: Ronald G. Minnich <rminnich@chromium.org> Reviewed-on: http://review.coreboot.org/1286 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Diffstat (limited to 'src/lib/memmove.c')
0 files changed, 0 insertions, 0 deletions