zyma98 wrote: > Checking like this seems really expensive in both size and runtime > performance. I'm a little skeptical this is actually usable. > > Is something like -fstack-clash-protection not usable in this context?
Thanks for the comments! This new option is different from `-fstack-clash-protection` because it doesn't assume a hardware protection mechanism. `-fstack-clash-protection` probes the stack but relies on configured memory protection unit (MPU) on Cortex-M or physical memory protection (PMP) on RISC-V to trap the illegal access. The added prologue is actually very cheap in practice. Since compilers tend to inline functions a lot, the added prologue is usually very small compared to the function body, so the overhead is not significant. We also have empirical evidence from our published paper linked below. In Table 3, the difference between the row `Hopter-seg-stack` and `Hopter-soft-lock` is caused by the added prologue, and the CPU usage doesn't change much for a drone flight control firmware. https://dl.acm.org/doi/pdf/10.1145/3711875.3729149 https://github.com/llvm/llvm-project/pull/208076 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
