On 5/23/21 5:14 AM, Bruno Haible wrote:
I agree that these handlers are _usually_ small and don't have nested functions. But a restriction is a restriction, and should be documented as such. Find attached a proposed patch.
Thanks, that looks good except please change "create nested functions" to "create and then use nested functions", as it's OK to for a stack-overflow handler to create a nested function without using it.
Should a similar restriction be documented for libsigsegv, or is that library immune to this problem?
No, "gcc -fno-trampolines" doesn't get rid of the need to have an executable stack. In the attached sample code gcc-closure.c, GCC 11.1 produces identical code with "gcc -fno-trampolines" than with "gcc -ftrampolines".
Ouch, I didn't know that -fno-trampolines doesn't work for C or C++. The GCC manual implies otherwise. I filed a GCC doc bug report here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100735
I think we should get clarity first, regarding which of the three approaches (static allocation, malloc, alloca) is preferrable. I'll try to write documentation for it.
If I understand you correctly, all three approaches will work if stack-overflow handlers don't create and use nested functions, and alloca will work even if nested functions are used.
The main problem is: what size to allocate for the alternate stack? If I understand recent glibc discussions correctly, the "right" size might vary dynamically even within a thread, which makes any approach problematic if it doesn't want to allocate an alternate stack large enough to be future-proof. This is where I hope Florian Weimer's proposed approach will rescue us somehow.
