This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fwd: What can a signal handler do with SIGSTKSZ?
On Fri, Jan 11, 2019 at 3:00 PM Florian Weimer <fweimer@redhat.com> wrote:
> * Zack Weinberg:
> > Now, if 8192 bytes is not enough to call some async-signal-safe
> > functions, that's another problem and one I would like to see
> > addressed by making the unwind library more space-efficient or
> > something along those lines.
>
> Small nit: This is unrelated to async-signal-safe functions because size
> considerations also apply to synchronously delivered signals, where few
> (if any) restrictions exist.
Yeah, I was just using "async-signal-safe functions" as a convenient
proxy for "functions we know people are likely to try to call from a
signal handler of any kind."
I was pretty harsh on Carlos's proposal but, on further reflection,
given the fairly nasty ABI compatibility constraints we're working
with here (SIGSTKSZ having to be usable as the size of a statically
allocated char[], for instance), I could live with _most_ of it. The
only change I insist on is, by hook or by crook we _must_ find a way
to make it safe to call `_exit` and `abort`.
Do you think we could push the kernel people to expose the space
requirement of a signal frame in some fashion that we could wrap up in
a new sysconf() constant? Then we could deprecate the constants, in
the same way that long ago PAGESIZE was replaced by
sysconf(_SC_PAGESIZE).
zw