Re: SIGSTKSZ is now a run-time variable

[Zack Weinberg <zackw@panix.com>]

On Tue, Mar 9, 2021 at 10:23 AM Eric Blake via Libc-alpha
<libc-alpha@sourceware.org> wrote:
> [adding glibc and Austin group lists]
> On 3/6/21 12:50 PM, Bruno Haible wrote:
> > 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.

The rationale for this change, from the glibc side, is that various
CPU architectures (notably x86 and ARM, as I understand it) have been
adding extensions that break the above premises.  The amount of space
required by the ucontext_t object (third argument to a SA_SIGINFO
signal handler) depends not only on the ISA and ABI but on the exact
set of ISA extensions that are available on the model of CPU that
happens to be running the program today.  Moreover, some of these
extensions require a great deal of space to store e.g. large SIMD
vector registers -- more than will fit in the fairly small MINSIGSTKSZ
we've historically provided (usually something like 2048 bytes).  And
there isn't anywhere else we / the kernel can save this state.

I was worried about exactly this kind of breakage when the patches
were originally being discussed, but _something_ has to give here and
I don't know what else it could be.   cc:ing H.J. and Florian, who
were more deeply involved.

zw