> On Wed, Oct 14, 2009 at 3:23 AM, Masatake YAMATO <[email protected]> wrote:
>> Hi,
>>
>>> Except the Makefile part, others would apply fine:
>>>
>>> patching file testcases/kernel/syscalls/getuid/Makefile
>>> Hunk #1 FAILED at 16.
>>> 1 out of 1 hunk FAILED -- saving rejects to file
>>> testcases/kernel/syscalls/getuid/Makefile.rej
>>> patching file testcases/kernel/syscalls/getuid/getuid01.c
>>> patching file testcases/kernel/syscalls/getuid/getuid02.c
>>> patching file testcases/kernel/syscalls/getuid/getuid03.c
>>
>> Sorry. I forgot to update my local copy.
>>
>> I've just recreated the patch with newer build system.
>>
>> To apply getuid-20091015.patch use -p0 option.
>> Put compat_uid.h at testcases/kernel/syscalls/utils/compat_uid.h.
>> Put compat_16.h. at testcases/kernel/syscalls/getuid/compat_16.h.
>>
>> I've just modified Makefile since last submitting.
>>
>>
>> Signed-off-by: Masatake YAMATO <[email protected]>
>
> Looks good! One question (just for my personal curiosity), is
> __NR_geteuid a 16-bit syscall? I'm asking because of this code...
>
> UID_T
> GETUID(void)
> {
> return syscall(__NR_getuid);
> }
>
> UID_T
> GETEUID(void)
> {
> return syscall(__NR_geteuid);
> }
>
> If so, what's the 32-bit syscall constant?
I'll explain __NR_getuid32. The explanation may be applicable to __NR_geteuid32.
I introduce this hack to keep Makefile and runtest/syscalls simple.
On 32 bit architecture(like i386)
---------------------------------
__NR_getuid32 is hardcoded in getuid() and geteuid() implementation of
glibc. So if you want to use newer __NR_getuid32, use getuid().
This knowledge is converted to source code as:
UID_T
GETUID(void)
{
return getuid();
}
If you want to use older one, here syscall is needed.
Let's look header file:
$ uname -m
i686
$ cat /etc/redhat-release
Fedora release 11 (Leonidas)
$ grep getuid /usr/include/asm/unistd_32.h
#define __NR_getuid 24
#define __NR_getuid32 199
We have found __NR_getuid is for older one.
This knowledge is converted to source code as:
UID_T
GETUID(void)
{
return syscall(__NR_getuid);
}
We can observe above macro works fine with strace:
$ strace ./getuid01 2>&1 | grep getuid
execve("./getuid01", ["./getuid01"], [/* 25 vars */]) = 0
getuid32() = 500
write(1, "getuid01 1 TPASS : getuid()"..., 47getuid01 1 TPASS :
getuid() returned 500
We can know strace represent getuid() invocation on i686 "getuid32()".
$ strace ./getuid01_16 2>&1 | grep getuid
execve("./getuid01_16", ["./getuid01_16"], [/* 25 vars */]) = 0
getuid() = 500
write(1, "getuid01_16 1 TPASS : getui"..., 50getuid01_16 1 TPASS
: getuid() returned 500
strace represent syscall(__NR_getuid) invocation on i686 "getuid()".
On 64 bit architecture(like x86_64)
-----------------------------------
There is only one getuid on such architecture.
There is no variant.
$ uname -m
x86_64
$ grep getuid /usr/include/asm/unistd_64.h
#define __NR_getuid 102
__SYSCALL(__NR_getuid, sys_getuid)
So
UID_T
GETUID(void)
{
return syscall(__NR_getuid);
}
and
UID_T
GETUID(void)
{
return getuid();
}
are the same. It means the test cases foo_16 and foo are the same on
x86_64. Actually strace says:
$ strace ./getuid01_16 2>&1 | grep getuid
execve("./getuid01_16", ["./getuid01_16"], [/* 39 vars */]) = 0
getuid() = 500
write(1, "getuid01_16 1 TPASS : getui"..., 50getuid01_16 1 TPASS
: getuid() returned 500
$ strace ./getuid01 2>&1 | grep getuid
execve("./getuid01", ["./getuid01"], [/* 39 vars */]) = 0
getuid() = 500
write(1, "getuid01 1 TPASS : getuid()"..., 47getuid01 1 TPASS :
getuid() returned 500
It is better not to build foo_16 on x86_64. But I think this is
smaller problem.
Masatake YAMATO
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
