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

[Garrett Cooper <yanegomi@gmail.com>]

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?

Thanks,
-Garrett

------------------------------------------------------------------------------
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