|
From: <sv...@va...> - 2005-03-31 09:09:10
|
Author: tom
Date: 2005-03-31 10:09:07 +0100 (Thu, 31 Mar 2005)
New Revision: 3490
Modified:
trunk/coregrind/vg_syscalls.c
trunk/coregrind/x86-linux/syscalls.c
Log:
Implement the gettid system call which seems to have got lost in the merg=
e.
Modified: trunk/coregrind/vg_syscalls.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/vg_syscalls.c 2005-03-31 07:59:35 UTC (rev 3489)
+++ trunk/coregrind/vg_syscalls.c 2005-03-31 09:09:07 UTC (rev 3490)
@@ -2956,6 +2956,12 @@
RES =3D 1;
}
=20
+PRE(sys_gettid, 0)
+{
+ PRINT("sys_gettid ()");
+ PRE_REG_READ0(long, "gettid");
+}
+
static void common_post_getrlimit(ThreadId tid, UWord a1, UWord a2)
{
POST_MEM_WRITE( a2, sizeof(struct vki_rlimit) );
Modified: trunk/coregrind/x86-linux/syscalls.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/x86-linux/syscalls.c 2005-03-31 07:59:35 UTC (rev 348=
9)
+++ trunk/coregrind/x86-linux/syscalls.c 2005-03-31 09:09:07 UTC (rev 349=
0)
@@ -1246,7 +1246,7 @@
GENXY(__NR_fcntl64, sys_fcntl64), // 221
GENX_(222, sys_ni_syscall), // 222
GENX_(223, sys_ni_syscall), // 223
- // (__NR_gettid, sys_gettid), // 224 */Linux
+ GENX_(__NR_gettid, sys_gettid), // 224 */Linux
=20
// (__NR_readahead, sys_readahead), // 225 */(Linux?)
GENX_(__NR_setxattr, sys_setxattr), // 226
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-31 14:55:42
|
On Thu, 31 Mar 2005 sv...@va... wrote:
> +PRE(sys_gettid, 0)
> +{
> + PRINT("sys_gettid ()");
> + PRE_REG_READ0(long, "gettid");
> +}
> +
It does nothing? Surely there should be a comment explaining what is
happening here?
N
|
|
From: Tom H. <to...@co...> - 2005-03-31 15:40:18
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Thu, 31 Mar 2005 sv...@va... wrote:
>
>> +PRE(sys_gettid, 0)
>> +{
>> + PRINT("sys_gettid ()");
>> + PRE_REG_READ0(long, "gettid");
>> +}
>> +
>
> It does nothing? Surely there should be a comment explaining what is
> happening here?
Of course it does something - after the pre handler runs the system
call will be run in the usual way and return a result. With the new
threading model no special handling is needed for gettid.
One thing that is odd is that I think that should be a linux specific
system call but the 2.4 code definitely has it in the generic ones and
the "Linux" marker against the entry in x86-linux/syscalls.c is
missing in the 2.4 code base but present in the 3.0 code base.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-03-31 15:53:24
|
> One thing that is odd is that I think that should be a linux specific > system call but the 2.4 code definitely has it in the generic ones and > the "Linux" marker against the entry in x86-linux/syscalls.c is > missing in the 2.4 code base but present in the 3.0 code base. That's probably a me-induced merge bogon -- the "Linux" marker might have come from my code line but the actual location of it from the 2.4 line. I agree, it should be a linux-specific one. J |
|
From: Nicholas N. <nj...@cs...> - 2005-03-31 17:17:29
|
On Thu, 31 Mar 2005, Tom Hughes wrote:
>>> +PRE(sys_gettid, 0)
>>> +{
>>> + PRINT("sys_gettid ()");
>>> + PRE_REG_READ0(long, "gettid");
>>> +}
>>> +
>>
>> It does nothing? Surely there should be a comment explaining what is
>> happening here?
>
> Of course it does something - after the pre handler runs the system
> call will be run in the usual way and return a result. With the new
> threading model no special handling is needed for gettid.
Ok... I'll engage my brain before commenting next time :)
N
|