Hacker News Reader

As an example of this, Zoxc has been trying to get stack probe support into LLVM for two years to no avail [0]. This is important to make sure that stack overflow or buffer overrun actually trigger the guard page and cause termination.

I admit it's not really fair to LLVM to pick on one patch like this but it's frustrating to me even as an outsider.

[0]: https://reviews.llvm.org/p/Zoxc/

View on HN

Zoxc has repeatedly refused reasonable requests to alter the patch to fit the standards of upstream. Because of this (and because I am rather tired of not having stack probes, with my embedded system not having functional guard pages), I'll make a hostile fork of their patch soon and get it through the pipeline. Stay tuned.

Ah, interesting. I hadn't gleamed that from the threads. It's great to hear that there's a chance that this will be supported though!

Late comment, but aren't stack probes entirely predicated on having working guard pages? I.e. they only exist to guarantee that the guard page is accessed before anything else, when a frame is larger than the page.

Is that just a stack canary? Hasn't gcc had this for years?

No, stack canaries are different. Stack canaries defend against some classes of buffer overflows. Stack probes defend against some classes of stack overflows.

Reply on news.ycombinator.com