bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSOC] Porting Valgrind to Hurd


From: Subhashish Pradhan
Subject: Re: [GSOC] Porting Valgrind to Hurd
Date: Tue, 25 Mar 2014 08:15:52 +0530

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



reply via email to

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