Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34

[Paul Eggert]

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.