|
From: Nicholas N. <nj...@ca...> - 2004-10-12 17:22:23
|
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
|