Sorry cartman, it's actually your fault here. Don't upgrade the kernel headers when upgrading the kernel. You should have one set of stable kernel headers that are known to compile in userspace programs and you should not touch it.

/usr/include/linux/list.h:579:2: warning: #warning "don't include kernel headers in userspace"

Nope nope if I dont use 2.6 kernel headers glibc wont have epoll,sysenter support etc. 2.6 kernel will ship its own headers so valgrind better get fixed...

We need a set of working kernel headers that are supposed to work for userspace. The standard kernel headers aren't those. As the warning you've pasted shows (and I've pointed it out), you are not supposed to include those headers in userspace programs.

Ok lets keep this bug open until 2.6.0 out but if you look at recent LKML discussion abous how cdrecord fails to compile with recent headers , you will see that I am supposed to use 2.6 headers...

thiago, valgrind is not a normal KDE application, it has to include kernel
headers since it docks itself into a layer between the libc and the kernel. 

hmm, I can't actually reproduce the problem with my 2.6test9. 

whats in /usr/include/linux/spinlock.h:571 for you?

I got preempt_disable(); there. I got a small hack I think. I will post for review If I can get it to work.

No luck with my hack. Btw this is -mm2 but preempt_disable() is from Linus' tree.

Created attachment 3268 [details]
Patch/Hack to make it compile on 2.6.0-test9-mm2 kernel

The best way I found to fix this.

Note that the actual problem I suspect is we need a glibc abstraction of :

linux/list.h
linux/thread_info.h

A workaround that I've seen someone recommend is that programs such as valgrind ship their own kernel headers -- or version thereof. It's clear from what you've told me that glibc headers are a no-go. And it's hard as well to work with something that tells you "you shouldn't be including this".

Anyways, before the kernel headers cleanup project comes to life, that's the only way out I know of.

The ABI is supposed to be stable, therefore it doesn't matter whether you're using 2.4 or 2.6's headers to build valgrind (or kscd for that matter).

Subject: valgrind

CVS commit by mueller: 

this should fix compilation on weird kernel 2.6.x installations.
CCMAIL: 68360@bugs.kde.org


  M +4 -4      coregrind/vg_syscalls.c   1.59
  M +0 -1      coregrind/vg_unsafe.h   1.22
  M +13 -0     include/vg_kerneliface.h   1.8


--- valgrind/coregrind/vg_syscalls.c  #1.58:1.59
@@ -2488,5 +2488,5 @@ PRE(ioctl)
 #       endif
 
-   case IIOCGETCPS:
+   case VKI_IIOCGETCPS:
       /* In early 2.4 kernels, ISDN_MAX_CHANNELS was only defined
        * when KERNEL was. I never saw a larger value than 64 though */
@@ -2498,5 +2498,5 @@ PRE(ioctl)
                      * 2 * sizeof(unsigned long) );
       break;
-   case IIOCNETGPN:
+   case VKI_IIOCNETGPN:
       SYSCALL_TRACK( pre_mem_read, tid, "ioctl(IIOCNETGPN)",
                      (UInt)&((isdn_net_ioctl_phone *)arg3)->name,
@@ -2887,5 +2887,5 @@ POST(ioctl)
 #       endif
 
-   case IIOCGETCPS:
+   case VKI_IIOCGETCPS:
       /* In early 2.4 kernels, ISDN_MAX_CHANNELS was only defined
        * when KERNEL was. I never saw a larger value than 64 though */
@@ -2897,5 +2897,5 @@ POST(ioctl)
                    * 2 * sizeof(unsigned long) );
       break;
-   case IIOCNETGPN:
+   case VKI_IIOCNETGPN:
       if (res == 0)
          VG_TRACK( post_mem_write, arg3, sizeof(isdn_net_ioctl_phone) );

--- valgrind/coregrind/vg_unsafe.h  #1.21:1.22
@@ -58,5 +58,4 @@
 #include <linux/sem.h>    /* for struct sembuf */
 
-#include <linux/isdn.h>   /* for ISDN ioctls */
 #include <scsi/sg.h>      /* for the SG_* ioctls */
 #include <sched.h>        /* for struct sched_param */

--- valgrind/include/vg_kerneliface.h  #1.7:1.8
@@ -372,4 +372,17 @@ struct vki_ucontext {
 #define VKI_ERESTARTSYS     512     /* Restart the syscall */
 
+/* Copied from linux/isdn.h */
+
+#define VKI_IIOCGETCPS  _IO( 'I',21 )
+#define VKI_IIOCNETGPN  _IO( 'I',34 )
+
+#define ISDN_MSNLEN          32
+
+typedef struct {
+    char name[ 10 ];
+    char phone[ ISDN_MSNLEN ];
+    int  outgoing;
+} isdn_net_ioctl_phone;
+
 
 /* Gawd ... hack ... */

Dirk you beated me again! :)