Define and enforce a fixed-stack safety contract

[drpaneas]

Summary

The runtime has chosen fixed goroutine stacks, but the current design still behaves like split-stack support exists in a few places while providing no hard overflow detection.

Why

• Overflow currently risks silent memory corruption instead of a controlled failure.
• stack_guard exists as metadata, but there is no actual enforcement.
• This is a foundational runtime safety issue, especially on a 16 MB target with fixed 64 KB goroutine stacks.

Evidence

• runtime/runtime_sh4_minimal.S: build expects -fno-split-stack and says split-stack support has been removed.
• runtime/splitstack.c: split-stack ABI functions are mostly stubs, and __splitstack_find() always returns NULL.
• runtime/stack.c: stacks have a guard value, but there is no hard guard-page or overflow trap.

Direction

• Pick one model and make it real: either true segmented/growable stacks or fixed stacks with enforced overflow detection.
• Add red-zone checks, canaries, or SP bounds checks at safe runtime boundaries.
• Add stack-usage telemetry to help size stacks and debug real workloads.

Related

• Investigate stack overflow detection without split-stack prologues #4
• Detect large fixed-size arrays that would overflow goroutine stacks #5