https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99486
Bug ID: 99486
Summary: Feature request: -fstack-check option for embedded
processors
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dcrocker at eschertech dot com
Target Milestone: ---
The -fstack-check option merely adds code to probe the end of the new stack and
relies on the hardware and operating system supporting memory paging to do the
actual checking. This makes it useless for embedded system development using
e.g. ARM Cortex processors. In particular, when developing embedded systems
using RTOS on processors with limited RAM, the amount of stack provided to each
task must be optimised to avoid wasting RAM; but this is difficult to do
without stack checking. Some RTOS provide a mechanism to check that a stack
canary at the limit of the stack hasn't been overwritten whenever a task is
descheduled; but this isn't reliable because the stack may overflow without the
canary being overwritten, or the program may crash before the stack check
happens. The -fstack-limit option of gcc is of no use in systems using RTOS
because the stack limit is different for each task.
I propose an additional option for implementing -fstack-check that does not
require memory paging hardware. This option would have the compiler call a
stack-check function near the start of the code generated for each function. A
single parameter would be passed to that function, which would be the lowest
(if the stack grows downwards) stack address used in the remainder of the
function. Similarly, when allocating objects of dynamic size on the stack, the
stack check function would be called.
The stack check function would be provided by the user or by an RTOS library.
It would typically check the address passed against the stack limit for the
current task, and if the stack limit would be exceeded, terminate the program
or task with suitable logging of the error. In a development environment it
could also record the greatest amount of stack ever used by each task.
