[Valgrind-developers] Linux header swamps

[Nicholas N. <nj...@ca...>]

Hi,

I've rewritten the vg_kerneliface.h file.  It's pretty similar to the old 
version, but I've copied things more faithfully from the the kernel 
sources (2.6.8.1, the latest), and cleaned up some of the mess.  There are 
a couple of trickier bits I'm still not sure about, which someone here 
might be able to help with.


- There's a constant __KERNEL__ that's important -- certain types have 
different meanings depending on whether it is set.  Eg. this code from 
linux-2.6.8.1/include/linux/types.h:

   #ifdef __KERNEL__
   typedef __kernel_uid32_t        uid_t;
   typedef __kernel_gid32_t        gid_t;
   typedef __kernel_uid16_t        uid16_t;
   typedef __kernel_gid16_t        gid16_t;

   [snip]

   /* libc5 includes this file to define uid_t, thus uid_t can never change
    * when it is included by non-kernel code
    */
   #else
   typedef __kernel_uid_t          uid_t;
   typedef __kernel_gid_t          gid_t;
   #endif /* __KERNEL__ */

If __KERNEL__ is set, uid_t is 32 bits;  otherwise it's 16 bits 
(__kernel_uid_t is 16 bits).  I think __KERNEL__ controls whether code is 
included in the kernel headers put in eg. /usr/include/linux/, but I'm not 
sure -- for our purposes in Valgrind, is it right to assume __KERNEL__ is 
set?

Similar, I think we need to assume __KERNEL_STRICT_NAME__ and __ASSEMBLY__ 
are not set, but I don't exactly understand why.

- Some time between 2.4.6 and 2.6.18, SIGRTMAX changed from 63 to 64. Is 
changing Valgrind's value (ie. VKI_SIGRTMAX) to 64 likely to break 
anything?  I couldn't tell from the code.

- In vg_main.c, we use VKI_AT_NULL and VKI_AT_SYSINFO.  We also use 
AT_NULL and AT_SYSINFO -- the glibc versions -- which have the same 
values.  Surely we can drop the use of VKI_AT_* here?  (It's right to use 
the glibc types here, since we are #including the relevant glibc headers.)

- In elf_prpsinfo, the current Valgrind code makes the pr_uid and pr_gid 
fields Ints.  However, the kernel code says:

         __vki_kernel_uid_t      pr_uid;
         __vki_kernel_gid_t      pr_gid;

and those types are clearly 'unsigned short'.  So the part of the core 
dump being controlled by this type must be wrong?

- The current Valgrind code says:

   #define VKI_GDT_TLS_ENTRIES 3
   #define VKI_GDT_TLS_MIN     6
   #define VKI_GDT_TLS_MAX     (VKI_GDT_TLS_MIN + VKI_GDT_TLS_ENTRIES)

But the corresponding kernel code subtracts one from VKI_GDT_TLS_MAX. (Nb: 
the kernel calls it GDT_ENTRY_TLS_MAX.)  In vg_ldt.c, VKI_GDT_TLS_MAX 
seems to be used inconsistently -- in one place as if VKI_GDT_TLS_MAX 
indexes the element one past the end of the array, and in two places as if 
it indexes the last element in the array.  It looks like a bug -- is that 
the case?


It's unfortunate how complicated and messy this all is.  I find it 
surprising that the kernel's system call interface is apparently so messy 
and poorly defined...

N