On 12/22/2009 10:51 AM, Garrett Cooper wrote:

On Fri, Dec 18, 2009 at 8:03 AM, Subrata Modak
<subrata@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