This is the mail archive of the
mailing list for the glibc project.
Re: [RFC PATCH 0/5] arm64: Signal context expansion
On 09/15/2016 06:45 PM, Dave Martin wrote:
On Tue, Sep 13, 2016 at 06:02:45PM +0200, Florian Weimer wrote:
On 09/13/2016 05:52 PM, Dave Martin wrote:
Agreed. I'll need to think some more about how this should work in
Depending on some SVE implementations details (which I know nothing about, I
only saw some public overview slides), we may also need additional storage
space to preserve SVE registers in the dynamic linker. Due to lazy binding,
this code cn be called from a signal handler, so this needs to be factored
into stack size requirements as well.
Yes and no. The kernel SIGSTKSZ constants don't care about ld.so --
that's userspace overhead, not kernel overhead.
Well yes, so is jmp_buf. But I think you still should consider the full
At least the lazy binding stack overhead can be avoided with LD_BIND_NOW=1.
Problematic are register width extensions used for argument passing and
callee-saved registers whose width has been extended. Both are particularly
challenging to deal with if existing vector instructions clear the extension
part (which may be desirable for other reasons).
The size of the jmp_buf type is a concern as well.
The default PCS for SVE will not be introducing any extra save/restore
requirements for SVE -- i.e., everything is caller-save at public
interfaces, except for the FPSIMD register bits that are already callee-
save under the existing PCS.
Is it possible to pass arguments in the register extension parts? If
existing non-SVE code can clobber these bits, we need some adjustments
in libc to save and restore SVE state in some places (which may need
further stack space).
Again, for lazy binding, LD_BIND_NOW=1 will help temporarily, but
profiling code may need a separate fix.