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


Subhashish, le Wed 25 Jun 2014 15:58:11 +0530, a écrit :
> But I couldn't wrap my head around listing the generated mig interfaces for
> the traps in vki-scnums-gnu.h.

Err, mig does not have to do with traps. Traps are just the kernel
interface, mig is not involved there at all.  Mig only comes as a helper
for the particular case of the mach_msg trap, but you will mostly not
need that.

> The host system traps plus the syscalls( like __NR_rename are to be
> encapsulated within an rpc generated via mig - my guess)
> are to be listed there.

No. This file should just enumerate traps, not RPCs.  The situation is
different from other OSes.  Let me sum the situation up:

In Linux:

- system calls have a __NR_foo number
- m_syswrap/syswrap-* provide the wrapping implementation for each and
every system call.
- m_libcfile.c calls __NR_foo system calls to implement what valgrind
needs for its own use

In Hurd/Mach:
- traps have a trap number
- RPC have an RPC number
- RPC are done by calling the mach_msg trap.
- m_syswrap/syswrap-* will provide wrapping implementations for each and
every *trap*. There is no need to distinguish RPCs there, it will all be
handled by implementing the wrapper for the mach_msg trap.
- m_libcfile.c will make RPCs to implement what valgrind needs for its
own use.

> 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

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.


reply via email to

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