[Top][All Lists]

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

Re: GSOC - valgrind-hurd queries

From: Samuel Thibault
Subject: Re: GSOC - valgrind-hurd queries
Date: Wed, 4 Jun 2014 01:53:37 +0200
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Subhashish, le Wed 04 Jun 2014 05:03:53 +0530, a écrit :
> Second the in the log in line 38 we have "return VG_(do_syscall1)(__NR_dup,
> oldfd);" .

> The linux one just #defines it(__NR_dup) with a number, whereas darwin's
> does it with this VG_DARWIN_SYSCALL_CONSTRUCT_UNIX(41). How do we do it?
> Insights.

We don't do any syscall() function, we do an RPC.  That's where we'll
need to call RPC stubs generated by MIG, just like libc's read()
function actually calls the __io_read RPC stub.  As I mentioned already
in by mail on 29th may, in the meanwhile you can just stuff
vg_assert(0) for a start, to get something linked at all.

Here, dup is actually a complex one, because there's no such RPC. file
descriptors in the Hurd are implemented in the libc. Have a look at
libc's dup implementation, which is in glibc/sysdeps/mach/hurd/dup3.c.
You'll see that it actually deals with a _hurd_dtable array, which
contains the file descriptors.  That's the kind of thing you'll have to
implement to get coregrind to be able to use dup(). Not a full-fledged
version like in libc, with mutex_lock and everything. Just enough of it
so that coregrind is happy with it.


reply via email to

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