public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Wei Yongjun <yjwei@cn.fujitsu.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: ltp-list@lists.sourceforge.net
Subject: Re: [LTP] [PATCH] syscalls: fix some failure on arch X86_64
Date: Wed, 11 Nov 2009 13:03:44 +0800	[thread overview]
Message-ID: <4AFA45B0.7070608@cn.fujitsu.com> (raw)
In-Reply-To: <200911102333.55526.vapier@gentoo.org>



Mike Frysinger wrote:
> 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.
>   

In x86_64, it do this. And If we want to use __NR_rt_sigaction syscall
directly, we must fill the sa_restorer and set the RESTORER flag to
sa_mask. If we do not set the sa_restorer, kill will always cause
segment fault.

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

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

  reply	other threads:[~2009-11-11  5:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-10  9:38 [LTP] [PATCH] syscalls: fix some failure on arch X86_64 liubo
2009-11-11  1:28 ` liubo
2009-11-11  4:14   ` Garrett Cooper
2009-11-11  4:30     ` Wei Yongjun
2009-11-11  5:22     ` liubo
2009-11-11  4:33 ` Mike Frysinger
2009-11-11  5:03   ` Wei Yongjun [this message]
2009-11-16  8:13     ` Subrata Modak
2009-11-16  8:53       ` liubo
2009-11-26 11:11         ` Garrett Cooper
2009-11-27  5:33           ` liubo
2009-11-27  6:49             ` Garrett Cooper
2009-11-27  8:50               ` Garrett Cooper
2009-11-27 10:07                 ` liubo
2009-11-27 22:18                   ` Garrett Cooper
2009-11-29  1:22                     ` Wei Yongjun
2009-12-01  0:00                       ` Garrett Cooper
2009-12-09  7:29                         ` liubo
  -- strict thread matches above, loose matches on Subject: below --
2009-12-09  7:34 liubo
2009-12-09 12:14 ` Subrata Modak
2009-12-18 16:03 ` Subrata Modak
2009-12-22  2:51   ` Garrett Cooper
2009-12-22 13:12     ` liubo
2010-02-22  5:21 liubo
2010-02-22  7:56 ` Garrett Cooper
2010-02-22  9:08   ` liubo
2010-02-22 18:05     ` Garrett Cooper
2010-02-23  0:59       ` liubo
2010-02-25  7:26         ` liubo
2010-02-25 10:00           ` Garrett Cooper
2010-02-26  0:35             ` liubo
2010-02-27  4:12               ` Garrett Cooper
2010-02-22  9:20 liubo
2010-02-22 14:45 ` Rishikesh K Rajak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AFA45B0.7070608@cn.fujitsu.com \
    --to=yjwei@cn.fujitsu.com \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=vapier@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox