On Tue, Nov 10, 2009 at 5:28 PM, liubo <[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
