[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
- Re: GSOC - valgrind-hurd queries, (continued)
- Re: GSOC - valgrind-hurd queries, Subhashish, 2014/06/01
- Re: GSOC - valgrind-hurd queries, Samuel Thibault, 2014/06/01
- Re: GSOC - valgrind-hurd queries, Subhashish, 2014/06/03
- Re: GSOC - valgrind-hurd queries, Samuel Thibault, 2014/06/03
- Message not available
- Message not available
- Message not available
- Message not available
- Re: GSOC - valgrind-hurd queries, Subhashish, 2014/06/25
- Re: GSOC - valgrind-hurd queries, Samuel Thibault, 2014/06/25
- Re: GSOC - valgrind-hurd queries, Subhashish, 2014/06/25
- Re: GSOC - valgrind-hurd queries, Samuel Thibault, 2014/06/26
- Re: GSOC - valgrind-hurd queries, Subhashish, 2014/06/27
- Re: GSOC - valgrind-hurd queries, Subhashish Pradhan, 2014/06/27
- Re: GSOC - valgrind-hurd queries,
Samuel Thibault <=