Hi, Subrata,
On 11/16/2009 04:13 PM, Subrata Modak wrote:
> Liubo,
>
> Are you sending an updated patch post this discussion ?
>
>   
Yes, I'll resend a updated patch about these rt_sigs.

Regards--
Liubo

> Regards--
> Subrata
>
> On Wed, 2009-11-11 at 13:03 +0800, Wei Yongjun wrote: 
>   
>> 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
>>     
>
>
>
>   

------------------------------------------------------------------------------
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 via email to