On Tuesday 10 November 2009 04:38:30 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 */
> };
>
> 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".which defeats the purpose of the test. there is no guarantee that the C library sigaction function is implemented via the __NR_rt_sigaction syscall. > 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. which is just as bogus and unportable. if the test needs a real time signal, it should leverage the sigrtmin...sigrtmax defines. -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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
