]> git.ipfire.org Git - thirdparty/valgrind.git/commitdiff
It seems there are some kernels around where the getpid system call has
authorTom Hughes <tom@compton.nu>
Sat, 16 Oct 2004 10:46:01 +0000 (10:46 +0000)
committerTom Hughes <tom@compton.nu>
Sat, 16 Oct 2004 10:46:01 +0000 (10:46 +0000)
been changed to return the ID of the thread group leader but which do not
have a gettid system call.

This breaks VG_(gettid) which assumes that the getpid system call will
give the thread ID if the gettid system call does not exist.

The (horrible) solution is to use readlink to see where /proc/self points
when the gettid system call fails.

BUG: 82114

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2771

coregrind/vg_mylibc.c

index 3929490508e279171f6cb1943be60e8499c6e1f7..691804c6e9b76675e38596077c2ac546ff62ae50 100644 (file)
@@ -232,8 +232,27 @@ Int VG_(gettid)(void)
 
    ret = VG_(do_syscall)(__NR_gettid);
 
-   if (ret == -VKI_ENOSYS)
-      ret = VG_(do_syscall)(__NR_getpid);
+   if (ret == -VKI_ENOSYS) {
+      Char pid[16];
+      
+      /*
+       * The gettid system call does not exist. The obvious assumption
+       * to make at this point would be that we are running on an older
+       * system where the getpid system call actually returns the ID of
+       * the current thread.
+       *
+       * Unfortunately it seems that there are some systems with a kernel
+       * where getpid has been changed to return the ID of the thread group
+       * leader but where the gettid system call has not yet been added.
+       *
+       * So instead of calling getpid here we use readlink to see where
+       * the /proc/self link is pointing...
+       */
+      if ((ret = VG_(do_syscall)(__NR_readlink, "/proc/self", pid, sizeof(pid))) >= 0) {
+         pid[ret] = '\0';
+         ret = VG_(atoll)(pid);
+      }
+   }
 
    return ret;
 }