Re: SIGSTKSZ is now a run-time variable

[Carol Bouchard]

Bruno:

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.

Carol

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.

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6c57d320484988e87e446e2e60ce42816bf51d53

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.

Carol

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

Hi,

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

Bruno

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