Re: SIGSTKSZ is now a run-time variable

Carol Bouchard via Libc-alpha <[email protected]>
Newsgroups gmane.comp.lib.glibc.alpha,gmane.comp.gnu.m4.bugs,gmane.comp.standards.posix.austin.general
Message-ID <CACkzpE5Hee6yLU26yoeP6PE7SW_Y59B1fHb4erm3FE2eduP1tw@mail.gmail.com>
M4 Experts:

Since this issue seems to be in a standstill, I've put together a patch
that I can use locally.
I'm seeking input for this patch I've produced for m4 package.  I'd
appreciate your thoughts.
Carol

On Tue, Mar 16, 2021 at 3:46 PM Carol Bouchard <[email protected]> wrote:

> Folks:
>
> I misstated earlier that the latest Fedora is going in this direction.
> This appears to be a glibc only issue as my build is pulling in glibc and
> not playing nicely with m4.
> According to https://pkgs.org/download/glibc-devel, fedora rawhide is
> pulling in the latest version glibc-devel 2.33.
> I'm wondering if there is a short-term work-around I can use.
>
> Carol
>
> On Tue, Mar 9, 2021 at 4:30 PM Scott Lurndal <[email protected]> wrote:
>
>> On Tue, Mar 09, 2021 at 08:58:38PM +0100, Bruno Haible via austin-group-l
>> at The Open Group wrote:
>> > Eric Blake wrote:
>> > > I can open a defect against POSIX if we decide that is needed, but
>> want
>> > > some consensus first on whether it is glibc's change that went too
>> far,
>> > > or POSIX's requirements that are too restrictive for what glibc wants
>> to do.
>> >
>> > Thanks for opening the discussion, Eric.
>> >
>> > Here are a couple of questions, to understand the motivation and the
>> possible
>> > alternative solutions to the problem:
>> >
>> > 1) As far as I understand, the issue occurs with certain x86 or x86_64
>> >    processors.
>> >
>> >    1.1) What has been the value of MINSIGSTKSZ on x86 and x86_64 so far?
>> >    1.2) What value of MINSIGSTKSZ is needed for AVX-512F support?
>> >    1.3) Will the trend to larger MINSIGSTKSZ values continue for Intel
>> >         processors?
>>
>> It's not just Intel processors.
>>
>> 64-bit ARM processors that support scalable vectors (SVE) support
>> vectors of up to 2084 bits, and they have 32 vector registers which would
>> require 8Kbytes for the SVE state alone if the implementation supports
>> the full 2kbits.
>>
>> scott
>>
>>
m4_glibc_SIGSTKSZ_issue.patch (text/x-patch, 2.6 KB)
diff --git a/third-party/m4-1.4.18-glibc-sigstksz.patch b/third-party/m4-1.4.18-glibc-sigstksz.patch
new file mode 100644
index 0000000..c506603
--- /dev/null
+++ b/third-party/m4-1.4.18-glibc-sigstksz.patch
@@ -0,0 +1,65 @@
+diff --git a/lib/c-stack.c b/lib/c-stack.c
+index 5353c08..863f764 100644
+--- a/lib/c-stack.c
++++ b/lib/c-stack.c
+@@ -51,13 +51,14 @@
+ typedef struct sigaltstack stack_t;
+ #endif
+ #ifndef SIGSTKSZ
+-# define SIGSTKSZ 16384
+-#elif HAVE_LIBSIGSEGV && SIGSTKSZ < 16384
++#define get_sigstksz()  (16384)
++#elif HAVE_LIBSIGSEGV
+ /* libsigsegv 2.6 through 2.8 have a bug where some architectures use
+    more than the Linux default of an 8k alternate stack when deciding
+    if a fault was caused by stack overflow.  */
+-# undef SIGSTKSZ
+-# define SIGSTKSZ 16384
++#define get_sigstksz() ((SIGSTKSZ) < 16384 ? 16384 : (SIGSTKSZ))
++#else
++#define get_sigstksz() ((SIGSTKSZ))
+ #endif
+ 
+ #include <stdlib.h>
+@@ -131,7 +132,8 @@ die (int signo)
+ /* Storage for the alternate signal stack.  */
+ static union
+ {
+-  char buffer[SIGSTKSZ];
++  /* allocate buffer with size from get_sigstksz() */
++  char *buffer;
+ 
+   /* These other members are for proper alignment.  There's no
+      standard way to guarantee stack alignment, but this seems enough
+@@ -203,10 +205,11 @@ c_stack_action (void (*action) (int))
+   program_error_message = _("program error");
+   stack_overflow_message = _("stack overflow");
+ 
++  alternate_signal_stack.buffer = malloc(get_sigstksz());
+   /* Always install the overflow handler.  */
+   if (stackoverflow_install_handler (overflow_handler,
+                                      alternate_signal_stack.buffer,
+-                                     sizeof alternate_signal_stack.buffer))
++                                     get_sigstksz()))
+     {
+       errno = ENOTSUP;
+       return -1;
+@@ -279,14 +282,15 @@ c_stack_action (void (*action) (int))
+   stack_t st;
+   struct sigaction act;
+   st.ss_flags = 0;
++  alternate_signal_stack.buffer = malloc(get_sigstksz());
+ # if SIGALTSTACK_SS_REVERSED
+   /* Irix mistakenly treats ss_sp as the upper bound, rather than
+      lower bound, of the alternate stack.  */
+-  st.ss_sp = alternate_signal_stack.buffer + SIGSTKSZ - sizeof (void *);
+-  st.ss_size = sizeof alternate_signal_stack.buffer - sizeof (void *);
++  st.ss_sp = alternate_signal_stack.buffer + get_sigstksz() - sizeof (void *);
++  st.ss_size = get_sigstksz() - sizeof (void *);
+ # else
+   st.ss_sp = alternate_signal_stack.buffer;
+-  st.ss_size = sizeof alternate_signal_stack.buffer;
++  st.ss_size = get_sigstksz();
+ # endif
+   r = sigaltstack (&st, NULL);
+   if (r != 0)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.