[Bug other/99486] New: Feature request: -fstack-check option for embedded processors

[Bug other/99486] New: Feature request: -fstack-check option for embedded processors

[dcrocker at eschertech dot com]

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.

[Bug other/99486] Feature request: -fstack-check option for embedded processors

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99486

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |ebotcazou at gcc dot gnu.org
   Last reconfirmed|                            |2021-03-09

--- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The -fstack-limit option of gcc is of no use in systems using RTOS because the
> stack limit is different for each task.

I don't think that's true, because you can either set a per-thread value in the
limit register or a per-thread value for the appropriate symbol; the latter was
done with VxWorks 6 for example, although it might not work with VxWorks 7.

> 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.

Contributions are always welcome!

[Bug middle-end/99486] Feature request: -fstack-check option for embedded processors

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99486

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|other                       |middle-end
           Severity|normal                      |enhancement