Re: [GSOC] Porting Valgrind to Hurd

[Samuel Thibault]

Hello,

Subhashish Pradhan, le Wed 19 Mar 2014 02:48:53 +0530, a écrit :
> Previously I had some discussions and queries related to this project
> on this mailing list, but disappeared for a while, my apologies.

No problem, welcome back :)

> I am working on implementing PRE() and POST() wrappers for a custom
> ioctl on Linux.

Ok, out of curiosity, what are you working on?

> With that as reference, I have the following (broad)
> steps in mind to complete the project:
> 
> 1. Investigate into the workings of the 46 system calls in
> gnumach/include/mach/syscall_sw.h and make a report of how to approach
> them (to be done before the coding period starts)

Yes, it is good that you get an idea of what this looks like, at least
to show that you understand how the work will look like.

You can however already note that a good part of them are not actually
needed: syscall_sw.h gives the declaration, but see kern/syscall_sw.c to
see which of them are actually implemented, that's actually a lot less,
boiling down to perhaps two dozens.

> 2. Implement the PRE() & POST() wrappers for each of the 46 system
> calls in valgrind source. (Specifically
> valgrind/coregrind/m_syswrap/syswrap-hurd.c)

Probably starting from the easiest ones (e.g. mach_task_self) and try
that already before trying more of them.  But even before that I guess
you will have to explain valgrind what a syscall looks like on Mach
(i.e. it's actually a trap).

The big part will be explaining valgrind how mach_msg_trap works, and
it's a complex one.  But once it's done, you'll get all the RPCs (done
through it) done.

> 4. Build a working source under an instance of Hurd - generation of
> makefiles, dependencies, and scripts. (The first deliverable)

That will probably be very early in the coding period actually. Better
get that working, then implement some PRE/POST, and check that those are
working.

> 5. If the time permits, my second deliverable would be a binary
> package for Debian/Hurd.

That should actually probably be quite easy: simply apply your patch to
the existing package, and see it compiled.

> Q1 - May I port the newest version of Valgrind or should it pose a problem?

Better start with the latest rather than having to merge with a newer
version.

> Q2 - Is there an equivalent of tracing program like strace in linux
> which can show what syscalls are being executed for a given program?

Mmm, I don't know about something for syscalls.  We do have rpctrace
which shows RPC calls, and that's usually what people need since it
shows filesystem operations etc. and even Mach functions are usually
performed via RPCs, not syscalls.  Syscalls are actually a rare thing in
a Hurd system: processes mostly make mach_msg_trap syscalls, to perform
RPCs.

Anybody knows about tracing the syscalls?
I don't see anything for that in the kernel.

Samuel