Garrett Cooper wrote:
> On Tue, Nov 10, 2009 at 5:28 PM, liubo <liubo2...@cn.fujitsu.com> 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.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
