Subhashish, le Thu 29 May 2014 04:57:55 +0530, a écrit : > This makelog[1] indicates that I should #include "vki/vki-gnu.h"[2]. > > Now this vki-gnu.h is supposed to be the gnu/hurd specific kernel interface > as the linux one ("vki/vki-linux.h") tells.
Ah, so that's the interesting part :) > Further there are warnings(I may ignore them, might I?) and errors - which > relate to "vki-gnu.h" - These are undeclared identifiers which will be > defined and maybe implemented (didn't look into it much) in that file. > > So should I > 1) pull all the kernel stuff with vki_ prefixes or > 2) step by step implement the types and constants to the kernel interface > and 'make' and see what's required? I'd say rather the latter. There will actually be very few things you need to implement, since the gnumach syscall interface is very small actually. One thing you need to understand well is that gnumach does *not* provide the posix interface, so things like uid_t, pollfd etc. do not make sense here :) Let's take the warnings/error one by one: ../include/pub_tool_vki.h:54:4: error: #error Unknown Plat/OS This one is easy :) Start with an empty vki-gnu.h, and include it :) ../include/pub_tool_libcfile.h:92:33: warning: 'struct vki_pollfd' declared inside parameter list [enabled by default] This one is interesting. It reveals that valgrind assumes that things like file operations are necessarily systems calls. They aren't in our case. They are instead *implemented in userland* in terms of the mach_msg system call. What you need to understand is that that code is about the system functions that valgrind needs to use for its own uses, and that it does not want to see analyzed by valgrind itself. That is why it is reimplemented in terms of system calls. The issue we have is that it's not so simple on GNU/hurd, so when one sees for instance: Int VG_(read) ( Int fd, void* buf, Int count) { Int ret; # if defined(VGO_linux) SysRes res = VG_(do_syscall3)(__NR_read, fd, (UWord)buf, count); # elif defined(VGO_darwin) SysRes res = VG_(do_syscall3)(__NR_read_nocancel, fd, (UWord)buf, count); # else it doesn't really directly make sense on GNU/Hurd. You can see in glibc/sysdeps/mach/hurd/read.c that read() actually calls _hurd_fd_read, from hurd/fd-read.c, which calls the __io_read() RPC function, which a mere function which packs the arguments and makes the mach_msg system call. I guess the proper way in our case is to use MIG to generate the __io_read() RPC function (or even copy/paste the generated output, but I guess MIG can be flexible enough that we can automatically generate what we need), to be compiled within valgrind, and in the VG_(read) function, call it the same way as glibc does it. That's however the eventual target. For now, I'd say in VG_(read) and others, add #elif defined(VGO_gnu) vg_assert(0); before the #else, so that you get to build something, but make sure we get trapped is we end up in that code, and thusly delay the actual implementation to when we will actually need it. Fortunately, valgrind does not seem to use too many of these, so we should not have to copy/paste too much from the libc. I guess a lot of these will not need to be implemented unless the user wants to use some special features of valgrind such as remote debugging etc. Concerning the original issue, vki_pollfd and alike, for now just replicate in vki-gnu.h what you find from /usr/include headers coming from the libc0.3-dev package, since that is what the RPC will mostly assume. Samuel