On Sun, Jan 08, 2023 at 06:58:42PM +0100, Willy Tarreau wrote:
> I'm currently testing it on various archs. For now:
>
> - x86_64 and arm64 pass the test
Thanks for testing.
> - i386 and arm fail:
> 59 sigactiontest_sigaction_sig(2): Failed to set a signal handler
> = -1 EINVAL [FAIL]
> 60 signaltest_signal_sig(2): Failed to set a signal handler
> = -1 EINVAL [FAIL]
I'll take a look at i386 for now.
> - riscv and mips build are now broken:
> sysroot/riscv/include/sys.h:1110:18: error: 'struct sigaction' has no member named 'sa_restorer'
> 1110 | if (!act2.sa_restorer) {
> | ^
> sysroot/riscv/include/sys.h:1111:34: error: 'SA_RESTORER' undeclared (first use in this function); did you mean 'SA_RESTART'?
> 1111 | act2.sa_flags |= SA_RESTORER;
> | ^~~~~~~~~~~
> | SA_RESTART
Just a speculation:
This is probably because not all architectures have a SA_RESTORER. I'll
need to figure out how Linux handles signal on those architectures.
> - s390 segfaults:
> 58 select_fault = -1 EFAULT [OK]
> 59 sigactionqemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
>
> It dies in __restore_rt at 1006ba4 while performing the syscall,
> I don't know why, maybe this arch requires an alt stack or whatever :
>
> 0000000001006ba0 <__restore_rt>:
> 1006ba0: a7 19 00 ad lghi %r1,173
> 1006ba4: 0a 00 svc 0
> 1006ba6: 07 07 nopr %r7
Bah, no clue on this. I'll CC s390 people in the next version and ask
them to shed some light.
> At the very least we need to make sure we don't degrade existing tests,
> which means making sure that it builds everywhere and that all those
> which build do work.
Understand.
> It would be nice to figure what's failing on i386. Given that both it
> and arm fail on EINVAL while both x86_64 and arm64 work, I suspect that
> once you figure what breaks i386 it'll fix the problem on arm at the
> same time. I had a quick look but didn't spot anything suspicious.
> Once we've figured this, we could decide to tag archs supporting
> sig_action() and condition the functions definition and the tests to
> these.
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
Hopefully, I can get it sorted before the weekend.
> The advantage of trying with i386 is that your regular tools and the
> debugger you used for x86_64 will work. I'm proceeding like this with
> the toolchains from https://mirrors.edge.kernel.org/pub/tools/crosstool/ :
>
> $ make nolibc-test LDFLAGS=-g CFLAGS=-g ARCH=i386 CC=/path/to/gcc-11.3.0-nolibc/i386-linux/bin/i386-linux-gcc
> $ gdb ./nolibc-test
> > b sigaction
> > run
> > s
> ...
Nice tip! I'll be playing with that.
> Note that the code looks correct at first glance:
>
> 0804b4a0 <__restore_rt>:
> 804b4a0: b8 ad 00 00 00 mov $0xad,%eax
> 804b4a5: cd 80 int $0x80
>
> I also think that the printf() in test_sigaction_sig() are not welcome
> as they corrupt the output. Maybe one thing you could do to preserve the
> info would be to prepend a space in front of the message and remove the
> LF. For example the simple patch below:
[...]
> Which is way more readable and still grep-friendly.
Yeah, that looks much better. Applied to my local git tree with
attribution.
--
Ammar Faizi
