3 ms·

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

by trasz 5y ago

jameshart 5y ago
A microcontroller programmer says: "What kernel?"
m_eiman 5y ago
… 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.
- trasz 5y ago
  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?
- StillBored 5y ago
  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.
  - formerly_proven 5y ago
    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.
- kevin_thibedeau 5y ago
  > 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.
ridaj 5y ago
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)
Const-me 5y ago
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.

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

by trasz 5y ago

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

jameshart 5y ago

A microcontroller programmer says: "What kernel?"

m_eiman 5y ago

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

trasz 5y ago
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?
StillBored 5y ago
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.
- formerly_proven 5y ago
  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.
kevin_thibedeau 5y ago
> 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.

ridaj 5y ago

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)

Const-me 5y ago

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.