Re: [LTP] [PATCH] syscalls: fix some failure on arch X86_64

[Wei Yongjun <yjwei@cn.fujitsu.com>]

Garrett Cooper wrote:
> On Tue, Nov 10, 2009 at 5:28 PM, liubo <liubo2009@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