4 ms·
> fixed sized automatic allocations [...] can be checked statically May I ask how you'd do this ? I need this for optimizing a C project.
by alcover 5y ago
> fixed sized automatic allocations [...] can be checked statically
May I ask how you'd do this ? I need this for optimizing a C project.
- cryptonector 5y agoCheck every function's automatic variables' sizes, add them all up, and add whatever function call frame size the compiler and ABI are using. Getting an exact accounting of function call stack memory usage is tricky because you might have framepointer-less code, and you might have inlining of function calls, but you can figure it out assuming no inlining and assuming you don't enable framepointer-less-ness.
- alcover 5y agoThank you. It doesn't err.. look super straightforward. I was hoping for an automated way of some sort. This stack affair of `local arrays are super fast! but keep it small, 1024 should be okay` is very puzzling to aspiring C lovers like me.
- cryptonector 5y agoThere's a way to dump DWARF debug information that you might then be able to parse and use to do just this.
- jart 5y agoYou can guarantee undetected stack overflow is impossible if you do two things. First you mprotect() a 4096 byte at the bottom of the stack. Second, you program the compiler to fail if an individual function allocates a stack frame larger than that. #ifndef STACK_FRAME_UNLIMITED #pragma GCC diagnostic error "-Wframe-larger-than=4096" #if __GNUC__ >= 9 #pragma GCC diagnostic error "-Walloca-larger-than=1024" #pragma GCC diagnostic error "-Wvla-larger-than=1024" #endif /* GCC 9+ */ #endif /* STACK_FRAME_UNLIMITED */
- alcover 5y agoOh! Now that's an actionable tip. I fail to see the relation between your first measure (which seems to act as a guard?) and the second. Also their sizes don't match. Though I'm afraid I'll encumber this thread with my naive questions.
- nwmcsween 5y agoWhy not mprotect + -fstack-clash-protection?