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

[Bruno Haible <bruno@clisp.org>]

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

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

[-- Attachment #2: c-stack-doc.diff --]
[-- Type: text/x-patch, Size: 849 bytes --]

diff --git a/lib/c-stack.h b/lib/c-stack.h
index 56d74f1..8bf773c 100644
--- a/lib/c-stack.h
+++ b/lib/c-stack.h
@@ -34,8 +34,10 @@
    A null ACTION acts like an action that does nothing.
 
    ACTION must be async-signal-safe.  ACTION together with its callees
-   must not require more than 64 KiB of stack space.  Also,
-   ACTION should not call longjmp, because this implementation does
+   must not require more than 64 KiB of stack space.  ACTION must not create
+   nested functions <https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html>,
+   because this implementation does not guarantee an executable stack.
+   Also, ACTION should not call longjmp, because this implementation does
    not guarantee that it is safe to return to the original stack.
 
    This function may install a handler for the SIGSEGV signal or for the SIGBUS

[-- Attachment #3: gcc-closure.c --]
[-- Type: text/x-csrc, Size: 697 bytes --]

/* Test whether a lexical closure created by GCC requires an executable stack.
   Compile this file with
     cross <target> gcc -O2 -S -fomit-frame-pointer gcc-closure.c
 */

extern int callback (void (*) (void));

int foo (void)
{
  int x = 0;

  void increment_x (void) { x++; }

  callback (increment_x);

  return x;
}

/* Result:
   i386       yes
   x86_64     yes
   m68k       yes
   mips       yes
   mips64     yes
   sparc      yes
   sparc64    yes
   alpha      yes
   hppa       ?
   hppa64     ?
   arm        yes
   arm64      yes
   powerpc    no
   powerpc64  no
   powerpc64-elfv2 no
   ia64       no
   s390       yes
   s390x      yes
   riscv32    yes
   riscv64    yes
 */