[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SIGSTKSZ is now a run-time variable

From: Carol Bouchard
Subject: Re: SIGSTKSZ is now a run-time variable
Date: Tue, 9 Mar 2021 09:34:35 -0500


Just wanted to add.......glibc has made this change and Not yet released Fedora has made this change among a number of other
packages.  This is the trend going forward.


On Mon, Mar 8, 2021 at 8:48 AM Carol Bouchard <cbouchar@redhat.com> wrote:
Hi Bruno:

This is the direction everyone is going in.  Here is an example of changes in glibc.  They're not the
only ones making this change.

Asked why the change? The response we received in regards to the signal change is as follows:
We don't have a choice. The old interfaces are simply incompatible with modern hardware. CPUs have massive register files nowadays. Applications using minimal signal stacks need to adapt in some way.


On Sat, Mar 6, 2021 at 1:53 PM Bruno Haible <bruno@clisp.org> wrote:

Carol Bouchard wrote in <https://lists.gnu.org/archive/html/bug-m4/2021-03/msg00000.html>:
> A change that was introduced is the
> #define SIGSTKSZ is no longer a statically defined variable.  It's value can
> only be determined at run time.
> # define SIGSTKSZ sysconf (_SC_SIGSTKSZ)

This is invalid. POSIX:2018 [1] defines two lists of macros:

  1) "The <signal.h> header shall define the following macros which shall
      expand to integer constant expressions that need not be usable in
      #if preprocessing directives:"

  2) "The <signal.h> header shall also define the following symbolic constants:"

SIGSTKSZ is in the second list. This implies that it must expand to a constant
and that it must be usable in #if preprocessing directives.

Besides being invalid, it is also not needed. The alternate signal stack
needs to be dimensioned according to the CPU and ABI that is in use. For example,
SPARC processors tend to use much more stack space than x86 per function
invocation. Similarly, 64-bit execution on a bi-arch CPU tends to use more stack
space than 32-bit execution, because return addresses and other pointers are
64-bit vs. 32-bit large. But once you have fixed the CPU and the ABI, there is
no ambiguity any more.

> This affects m4 code since the code assumes a statically defined variable which
> can be determined at preprocessor time.

POSIX guarantees this assumption.

> Please advise how I can get past this.

Fix your <signal.h>.


[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]