Hello, here is my initial coverage of teching valgrind ioctl.
Some notes have been left out, will fill it when I get some time - but need to prepare for university exams that are starting tomorrow. On Tue, Mar 25, 2014 at 6:32 AM, Samuel Thibault <samuel.thiba...@gnu.org> wrote: > Subhashish Pradhan, le Thu 20 Mar 2014 22:26:15 +0530, a écrit : >> 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? > > They are mostly outdated or non-implemented interfaces. At any rate, you > don't have to care about them. > >> I also found that there is a coregrind/m_syswrap/syswrap-darwin.c which has >> some mach wrappers. It'd be an interesting reference > > Most probably indeed. > >> Can a Darwin VM be used to study that or would it be a waste of time? > > I'd say just study the source code. > >> >> 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 > > Those system calls. > > Take care of understanding the difference between RPCs and system calls. > *All* RPCs go through the mach_msg_trap system call. It means > implementing mach_msg_trap correctly in valgrind gives you all RPCs > working. > >> >> 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? > > I'd say rather the current release. > >> Sorry for the big, detailed reply. > > No problem, on the contrary, that's what mails are good for. > > Samuel
