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

[Bruno Haible]

Paul Eggert wrote:
> > Now, you are arguing "let's ignore whether programs use nested functions".
> 
> Not at all. All I'm saying is, stack-overflow handlers shouldn't call 
> via pointers to nested functions.
> 
> There are already several restrictions on stack-overflow handlers; for 
> example, you can't call 'exit'. A restriction against calling via 
> pointers to nested functions is just another restriction - one that's 
> easier to comply with than the 'exit' restriction, in my experience.

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.

> If stack-overflow handlers absolutely can't live without calling via 
> pointers to nested functions, one can work around the problem by 
> compiling with gcc -fno-trampolines.

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".

> > being close to POSIX would mean to use SIGSTKSZ for the allocation
> > of an alternate stack, most likely through malloc.
> 
> That would also be a reasonable change to the test cases. I didn't do 
> that, partly because I thought it simpler just to allocate an enormous 
> alternate signal stack, partly because I wasn't yet entirely clear on 
> exactly when malloc is bad for allocating alternate signal stacks so I 
> wanted to avoid malloc entirely. But if you'd prefer that the test cases 
> use malloc I can rewrite them to do that.

Thanks for the offer. 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.

Bruno

c-stack-doc.diff
Description: Text Data

gcc-closure.c
Description: Text Data