This is the mail archive of the
mailing list for the glibc project.
Re: [RFC PATCH 0/5] arm64: Signal context expansion
On Mon, Sep 12, 2016 at 04:01:17PM +0100, Szabolcs Nagy wrote:
> On 12/09/16 12:17, Dave Martin wrote:
> >> On 09/09/2016 05:21 PM, Dave Martin wrote:
> >>> I wonder whether we should make the signal stack size runtime
> >>> discoverable through sysconf() instead...
> > I will likely suggest this for the future, but of course it doesn't help
> > for current binaries.
> > Note that MINSIGSTKSZ stared life wrong for arm64, and has since gone
> > through a few ABI breaking changes. I don't condone this, but we have
> > form in this area :/
> > sigaltstack() already fails with ENOMEM for software that passes
> > ss_size = MINSIGSTKSZ, and is built against glibc<2.22 , , running
> > on linux>=4.3 , which is an ABI break in case where sigaltstack() is
> > otherwise guaranteed to succeed.
> yes, this was abi breaking change.
> if glibc does not care about existing binaries
> that use sigaltstack with MINSIGSTKSZ then it can
> increase the size, but i think the kernel should
> not change the abi (there are other libcs and libc
> independent runtime systems on linux for aarch64
> with their own sigaltstack setup, not all of them
> may care about SVE).
> i assume the kernel can avoid saving SVE regs when
> they are not used by the process.
I can (and do), in my patches (not posted yet).
The real issue here is that a recently updated shared library might be
optimised to use SVE, where the program using it is an older, SVE-
(think of an optimised math library using some new fancy SVE-based
number crunching internally).
> > The bottom line here is that the sigaltstack() API is broken with regard
> > to extensibility, so we cannot extend the amount of signal state without
> > breaking something.
> extending signal state can break things independently
> of sigaltstack.
> binaries with strict guarantees about worst case stack
> usage can change behaviour.
Indeed, but this is not a new issue. Software must run with enough
stack in order to be portable, but there is no portable way to determine
how much stack is needed.
> fortunately glibc PTHREAD_STACK_MIN is huge on aarch64
> so applications using it are unlikely to break because
> of the increased signal state.
> (this also means it's impossible to have threads with
> tiny stacks on glibc, so large amount of threads means
> large amount of commit charge.)
Again, not a new problem.