[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSOC - valgrind-hurd queries

From: Subhashish
Subject: Re: GSOC - valgrind-hurd queries
Date: Sat, 31 May 2014 04:19:56 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On Thursday 29 May 2014 05:36 AM, Samuel Thibault wrote:
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

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)

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

The symbol VKI_PATH_MAX cannot be defined since symbol PATH_MAX is not defined[3]. Can we have workarounds - based on realloc, or like xgethostname() as described.

I'm following vki-linux.h and vki-gnu.h to add type definitions to vki-gnu.h - but I am in the dark as to what is to be added - I'm doing hit and trial.

VKI_PATH_MAX, VKI_S_IRUSR, VKI_S_IWOTH are the few of many symbols to be defined here.

The latter 2 are part of sys/stat.h in other unix systems - I suppose we don't do stat.h - Is there any equivalent to it, or we'll need workarounds here too?


3 - https://www.gnu.org/software/hurd/hurd/porting/guidelines.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]