On 12/22/2009 10:51 AM, Garrett Cooper wrote:
> 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
>
>
>
Hi, Garrett,
In my patch, I adopted a kind of method which is different from
your previous changes about this.
I try to find the address of "restore_rt" which is needed by
syscall rt_sigaction, and I managed to get this address by
tracing glibc function "sigaction".
After doing these, I also found rt_sigaction's "sigaction" struct is
different from normal "sigaction" struct, so when copy from normal
"sigaction" struct to rt_sigaction's kernel "sigaction" struct, some
kind of segmental fault will ocurr to us.
So, I did some changes to revert your previous changes and directly
adopted the function "restore_rt" and kernel "sigaction" struct to fix
these bugs.
Hope these are helpful to you.
Thanks,
-Liu Bo
------------------------------------------------------------------------------
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
