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