From: Wei Y. <yj...@cn...> - 2009-11-11 04:33:34
|
Garrett Cooper wrote: > On Tue, Nov 10, 2009 at 5:28 PM, liubo <liu...@cn...> wrote: > >> Hi, >> On 11/10/2009 05:38 PM, liubo wrote: >> >>> 1) rt_sigaction >>> "sigaction" has the structure: >>> >>> struct sigaction { >>> __sighandler_t sa_handler; >>> unsigned long sa_flags; >>> #ifdef SA_RESTORER >>> __sigrestore_t sa_restorer; >>> #endif >>> sigset_t sa_mask; /* mask last for extensibility */ >>> }; >>> > > Not true... from glibc 2.9 / gentoo-sources-2.6.30-r4: > > #ifdef __i386__ > /* Here we must cater to libcs that poke about in kernel headers. */ > > struct sigaction { > union { > __sighandler_t _sa_handler; > void (*_sa_sigaction)(int, struct siginfo *, void *); > } _u; > sigset_t sa_mask; > unsigned long sa_flags; > void (*sa_restorer)(void); > }; > > /* ... */ > > #else > > struct sigaction { > __sighandler_t sa_handler; > unsigned long sa_flags; > __sigrestore_t sa_restorer; > sigset_t sa_mask; /* mask last for extensibility */ > }; > > #endif > > What do the manpages say is required for rt_sigaction to function on > your machine? Mine just says: > > SYNOPSIS > #include <signal.h> > > int sigaction(int signum, const struct sigaction *act, > struct sigaction *oldact); > > Feature Test Macro Requirements for glibc (see feature_test_macros(7)): > > sigaction(): _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE > > >>> However, on arch x86_64, if we directly get to call rt_sigaction, >>> the argument "sa_restorer" will not be fulfilled, and this will lead >>> to segment fault. >>> on arch x86_64, if sa_restorer is not set, kernel will lead to segment fault. >>> In other arch, if sa_restorer is not set, kernel can do the correct work. >>> To avoid this segment fault, we use glibc function >>> "int sigaction(...);" instead, which can fulfill the argument "sa_restorer". >>> >>> 2) rt_sigprocmask >>> This failure contains two aspects, >>> the first is the segment fault as described in 1), >>> the second is that testcase uses a unknown signal 33 for test, >>> and this will lead sigaction cannot bind signal 33 to the action. >>> >>> So, we attempt to use a known signal instead, such as 34. >>> >>> >>> >> I am sure signal 32 and 33 cannot be used in rt_sigprocmask test >> on arch x86_64, but I'm not sure which signal else should be used >> here, Is there anyone can provide suggestions? >> > > RT signals are all signals above SIGRTMIN (typically 32+, but not > always), up to SIGRTMAX (usually 64, but on mips it's 128). So... why > is setting the signal number to anywhere between SIGRTMIN and SIGRTMAX > unacceptable? > Not sure why signal 32 and 33 are not accepted by sigaction() on x86_64, the acceptable signal from 34 to SIGRTMAX, maybe it's the glibc's BUG? since I had not found the source code of x86_64 sigaction(), I can not check this. It is very strange. |