Re: [GSOC] Porting Valgrind to Hurd

[Subhashish Pradhan]

Hello,

Thanks for feedback!

On Thu, Mar 20, 2014 at 9:00 PM, Samuel Thibault
<samuel.thibault@gnu.org> wrote:
> 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?

The starter task (teaching valgrind about ioctls; to use read/write
primitives of Valgrind) is performed as follows:
1 - writing of a dummy kernel module
2 - insmod-ing it into a running kernel
3 - writing a user program that uses this ioctl
4 - compiling valgrind
5 - invoking valgrind on the user application
6 - It reports there is an "unhandled ioctl 0x6b00 with no
size/redirection hints" and
     redirects me to a faq documentatiion README_MISSING_SYSCALL_OR_IOCTL
     to write PRE() and POST() wrappers - the syscall wrappers.
7 - I was stuck reading the code of
valgrind/coregrind/m_syswrap/syswrap-linux.c @ lines 5451
8 - a strace on the client tells me that the ioctl takes two parameters so
9 - from this and the ioctl wrapper code it seems that, I have to add some code
     to switch(ARG2 /* request */) but have been lazy to do so;
     May I do so after the student application deadline passes? - it's
making me unfocused

...

>
> 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.
>

I found kern/syscall_sw.c couple of days ago and was wondering about the
difference between the .h and .c variants; but I waited for your feedback.
The implemented traps matter. But are the others a dummy filler to be
implemented when required?

I also found that there is a coregrind/m_syswrap/syswrap-darwin.c which has
some mach wrappers. It'd be an interesting reference but I haven't gone through
the code.
Can a Darwin VM be used to study that or would it be a waste of time?
I think that if I delve into that I should do that during community
bonding period.

>> 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.
>

Hmm. Yes, that would be a better way - I could write client programs
that use those RPCs
and then invoke rpctrace and Valgrind on them and then proceed like
the workflow on the starter task.

...

>> 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.
>

By latest do you mean the trunk version, I presume? Or the current release?

Sorry for the big, detailed reply. I guess I should start blogging my reports.

Regards,
Subhashish Pradhan