[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSOC - Valgrind for Hurd
From: |
Samuel Thibault |
Subject: |
Re: GSOC - Valgrind for Hurd |
Date: |
Tue, 20 May 2014 22:50:07 +0200 |
User-agent: |
Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) |
Hello,
I would advise starting with trivial system calls, such as
mach_thread_self, mach_task_self, and mach_host_self, which don't take
any parameter, and just returns a port. That'll make you implement the
basic infrastructure for the trap call.
Then calls like task_terminate, task_suspend, etc., i.e. calls which
only take parameters and return a value, should be a matter of
explaining valgrind how parameters are passed to the kernel during the
trap.
Then calls like task_create or mach_port_allocate, i.e. calls which
return a value through a pointer, should be quite easy. At that point
you should be able to easily implement almost all of the system calls.
This won't be enough to run even a mere main() {} program, since libc
itself uses RPCs, but getting that infrastructure right will already be
plenty.
Then more hard stuff will come: vm_map, vm_allocate, vm_deallocate. One
will have to tell valgrind that these initialize or destroy a whole
area of memory. And last but not least, mach_msg_trap will be the most
complex one. You'll have to precisely check how the mach_msg_header_t
is dealt with according to flags etc. If that does not fit the gsoc,
I'd say it's not a problem, we can probably help you with it, once the
infrastructure is settled.
Samuel