On Fri, Dec 18, 2009 at 8:03 AM, Subrata Modak
<subr...@linux.vnet.ibm.com> wrote:
> Garret,
>
> Not sure if you applied this :-(
>
> Regards--
> Subrata
>
> On Wed, 2009-12-09 at 15:34 +0800, liubo wrote:
>> Here is the patch, which contains lots of adjustments
>> on style, so it might be a bit huge.
>>
>> Testcase 1. rt_sigaction01
>> On arch x86_64, if we directly get to call syscall
>> rt_sigaction, there will be "segment fault".
>> 1) One reason is that we must supply the flag of
>> "SA_RESTORER" and the correct pointer to the fuction
>> "restorer", according to the kernel code.
>> 2) The other reason is that default syscall rt_sigaction
>> use kernel "sigaction" structure, which is different
>> with normal "sigaction" structure.
>>
>> So,
>> 1) We manage to find the address of the function
>> "restorer" by using glibc function "sigaction",
>> which might be something tricky. Then we add these
>> arguments to make test run correctly.
>> 2) We also use kernel "sigaction" structure to fit
>> realtime syscall __NR_rt_sigaction.
>>
>> Testcase 2. rt_sigprocmask01
>> First, there exsits the same problem as rt_sigaction01.
>> Second, this testcase uses a unchanged signal number 33,
>> which may diff among different archs and lead to error
>> "unknown signal".
>>
>> So, we use a macro TEST_SIG which refers to SIGRTMIN
>> to replace 33.
>>
>> Testcase 3. rt_sigsuspend01
>> There exists the same problem as rt_sigaction01.
>>
>> This patch fixed these failure.
No, I didn't commit this because it's long, and I'm not sure if
it's doing the right thing as per my research over the past couple of
weeks. These tests are tricky because it requires a particular formula
of preset variables and structures in order to properly use
rt_sigaction, and that's where we're running into issues with them on
x86_64 -- because the syscall implementers decided to remain sort of
backwards compatible with x86, and that's why it's such a mess to deal
with.
I will look at the diff and pick out which parts are of value, but
a lot of this diff's contents are basically reverting the changes that
I made this month.
Thanks,
-Garrett
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
