On 12/28/22 1:49 AM, Willy Tarreau wrote:
I'll try to do it but do not want to make you wait too long in case it gets delayed. In the worst case we should only postpone the getauxval() patch and not the other ones.
I will split it into 2 patchset then.
BTW, do you think your arch-specific changes for sigaction() will be easily portable to other architectures ? I feel a bit wary of starting to have different features per architecture given the purpose of the lib, so the more uniform the coverage the better.
The 'rt_sigaction()' itself doesn't seem to be an arch specific, but the way it resumes the execution needs to call 'rt_sigreturn()' which is arch specific. I took a look at the kernel source code, most architectures read 'struct rt_sigframe' from the stack pointer.
https://github.com/torvalds/linux/blob/631aa744423173bf921191ba695bbc7c1aabd... https://github.com/torvalds/linux/blob/631aa744423173bf921191ba695bbc7c1aabd... https://github.com/torvalds/linux/blob/a6b450573b912316ad36262bfc70e7c3870c5... https://github.com/torvalds/linux/blob/a6b450573b912316ad36262bfc70e7c3870c5... https://github.com/torvalds/linux/blob/eb67d239f3aa1711afb0a42eab50459d9f3d6...
On the x86-64 arch, the implementation is just like this:
__arch_restore_rt: # # ((%rsp - sizeof(long)) must point to 'struct rt_sigframe') # # 'struct rt_sigframe' is automatically constructed by # the kernel when a signal is caught. # movl $0xf, %eax // __NR_rt_sigreturn == 0xf syscall
I believe aarch64 and RISCV don't behave differently, but different registers.
Not sure what PowerPC does here, it seems a bit different: https://github.com/torvalds/linux/blob/1612c382ffbdf1f673caec76502b1c00e6d35...
I haven't taken a look at other archs.
What do you think? Is it affordable for nolibc to implement all of these?