bug-hurd
[Top][All Lists]
Advanced

[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: Sun, 29 Jun 2014 20:02:45 +0200
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Subhashish, le Sat 28 Jun 2014 01:41:12 +0530, a écrit :
> On Wednesday 25 June 2014 04:24 PM, Samuel Thibault wrote:
> >Subhashish, le Wed 25 Jun 2014 15:58:11 +0530, a écrit :
> >>I assume the generated *.h and *.c files will have to be included into the
> >>vki-scnums-gnu.h file and then manipulate them into a trap-ped syscall.
> >No. The generated .c file will make the mach_msg trap for you. As a
> >caller of the functions generated by mig, you will not need to know
> >anything about the RPCs, but just call the functions from m_libcfile.c.
> >The .h file will contain the prototype for the function, e.g. for the
> >read() function, the .h file contains the RPC equivalent, __io_read
> >function:
> >
> >kern_return_t __io_read
> >(
> >     io_t io_object,
> >     data_t *data,
> >     mach_msg_type_number_t *dataCnt,
> >     loff_t offset,
> >     vm_size_t amount
> >);
> >
> >that's what you will call from m_libcfile.c, just passing the FD as
> >io_object, a data buffer, the data count, offset, and amount to be
> >transfered. No need for an RPC id here.
> 
> I did implement the trap declarations in vki-scnums-x86-gnu.h file.

Yes, but please see my comments dated 26th June.

> Then these __NR_syscalls (not the __NR_traps) - where do I declare them if
> not in vki-scnums-x86-gnu.h file?

Err, what do you call a syscall?  What I called "traps" are the GNU Mach
system calls. There is nothing else at the Mach layer.

> You mentioned that these will probably be the ones from glibc

They aren't syscalls, they are RPCs, which is another layer than
syscalls.

> - like the __io_read() rpc and if not then these will be generated by
> MIG right?  So I'll have to find a way to use the glibc ones without
> referring them directly as in #include stuff.

I don't think you strictly need to bother with them for now, since you
have made m_libcfile.c *not* call any libc function any more, and just
call vg_assert(0). So you should be able to link a valgrind binary
relatively soon.

You don't need to use the glibc MIG-generated files, you just need to
call MIG from the valgrind Makefile, similarly to how it is done in
glibc and hurd (see the *User rules), to produce your own version of the
.c and .h files.

> Also, FAQ recommends talking to organizations about how they handle
> evaluations and their disclosure to students. How do we do it? Would I get
> to know anything about it or would I know about it afterwards?

Well, I can at least say that I've written in the evaluation that
communication was not so good: we haven't seen you much on IRC, and
mails are not so frequents.  I however do believe that you can get to
something, even if not what we'd dream of :)

Samuel



reply via email to

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