This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: What can a signal handler do with SIGSTKSZ?


* Zack Weinberg:

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

abort delivers another signal, so that's going to be impossible to
support with a really small stack, I think.

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

That's an interesting idea.  sigaltstack could also check that the size
is at least that large, but then the question is how many sigaltstack
users check the error return value.

However, based on what I saw in the kernel sources, it's not that they
have an exact upper bound in the sources or even at run time.  I think
the code simply uses space as it proceeds (at least on x86).  But
perhaps I misread it.

Thanks,
Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]