On Sun, Jan 08, 2023 at 07:49:30PM +0100, Willy Tarreau wrote:
On Mon, Jan 09, 2023 at 01:31:17AM +0700, Ammar Faizi wrote:
I'll be pondering this code this week (to follow what actually the rt_sigaction wants on i386 and arm):
https://github.com/torvalds/linux/blob/v6.2-rc3/kernel/signal.c#L4404-L4434
Seems like it could simply be a matter of sigsetsize, which is the first one returning -EINVAL.
Hopefully, I can get it sorted before the weekend.
OK!
I couldn't dedicate much time to this, but I looked into it, and here's my report on the progress. I didn't manage to find a proper solution to this. But yes, you're right. It's a matter of 'sizeof(sigset_t)'.
So here is my observation. Currently, nolibc's sys.h includes this:
#include <asm/signal.h>
The definition of 'sigset_t' in that header is:
typedef unsigned long sigset_t;
On i386, 'sizeof(unsigned long)' is 4, but on x86-64 it's 8.
That is not the 'sigset_t' that the kernel wants. The kernel wants the 'sigset_t' that is in <asm-generic/signal.h>:
#define _NSIG 64 #define _NSIG_BPW __BITS_PER_LONG // this 64 on x86-64, but 32 on i386. #define _NSIG_WORDS (_NSIG / _NSIG_BPW)
typedef struct { unsigned long sig[_NSIG_WORDS]; } sigset_t;
The above struct is always 8 bytes in size. In other words:
_NSIG_WORDS == 2 on i386 _NSIG_WORDS == 1 on x86-64 sizeof(unsigned long) == 4 on i386 sizeof(unsigned long) == 8 on x86-64
Therefore, sizeof(unsigned long [_NSIG_WORDS]) is always 8 on both architectures. That's the correct size.
I tried to #include <asm-generic/signal.h> but it conflicts with the other 'sigset_t' definition. So I can't do that.
Why are there two different definitions of 'sigset_t'? I don't know.
I probably should read the story behind this syscall to get it implemented right. Let me ponder this again on Monday. But at least I tell what I have found so people can give some comments on it...