Hacker News Reader

Comment by trasz | Hacker News Reader

What’s the point of a low stack limit, apart from places like the kernel?

A microcontroller programmer says: "What kernel?"

Any environment with restricted memory resources compared to needs, and a need for reliable behavior

Embedded applications such as automotive, or industrial control come to mind (or even consumer electronics, with less life-or-death consequences possible)

… and embedded, of course. The main problem is that there IS a limit, and you have no idea what the limit is. The only way you find out is when you crash.

There is - in embedded (also kernel), but not in general purpose systems, like the Unix userspace. And the same piece of software very rarely runs on both. So, again, what’s the point of this exercise?

People have differing opinions of "embedded" but I would claim that most embedded uses cases the stack is actually specified by the programmer via linker scripts and/or manually setting it up during early bootstrap. Plus, its not exactly hard in most of these environments to write target and/or compiler specific macros which detects top of stack and can runtime check it via DEBUG() like macros or modifying function entry macros. None of this is of course portable, but neither is code designed to run in 1-16k of RAM and a few more K of flash.

OTOH, there seem to be a lot of "we don't control anything" IoT devices which are random overly powerful processors with random uboot+linux kernels+rootfs's running my_first_c_program.c level applications. All of it tossed together with very little engineering effort, and frequently less low level knowledge, and left to rot because its basically unmaintainable, even if it happens to be the 1% of devices that can get over the air updates.

gcc's -fstack-usage works well, at least for the kind of C I write on small microcontrollers. You still have to add it up manually across the callgraph and of course take ISRs into account.

> The only way you find out is when you crash.

You can fill the stack region with sentinel data and periodically scan it to warn of impending doom.

Virtual memory is not exactly free. To work fast, modern CPUs require quite a lot of data to be available in the on-chip caches. TLB cache is one of these pieces of data. When you reserve many GB of address space for stacks of many threads, the code running on these threads is less likely to hit that TLB cache.

I've heard that huge pages might help, unfortunately they're somewhat harder to use.

Reply on news.ycombinator.com