summaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas/valgrind.mdwn
diff options
context:
space:
mode:
authorantrik <antrik@users.sf.net>2011-03-16 03:00:08 +0100
committerantrik <antrik@users.sf.net>2011-03-25 23:32:09 +0100
commit2462ca1a8be02689b5e0c5a13038472ad29a7888 (patch)
tree960ad7932c9ab827fe73f2d245ee53a942d53760 /community/gsoc/project_ideas/valgrind.mdwn
parentd6f55e4eddd3ea30de9e4685059264cc4b3f21d8 (diff)
gsoc/project_ideas: Restore all project ideas here
While there is certainly some overlap with other areas, it is *not* acceptable to drop mentors and exercises from GSoC tasks, nor to add random crap, nor do any other changes that make them less useful as GSoC tasks -- and this is *not* obvious if they do not live in the project_ideas namespace. It's also confusing in general. I tried to preserve all valid changes to the task descriptions themself -- though I might have messed up some things. I did leave the now redundant entries in open_tasks in place. Not sure how to deal with them. As the content is virtually identical anyways, they probably should be just turned into stubs pointing here. Or don't list them explicitely at all -- we point out in other places that GSoC ideas are useful in other contexts too... For the future, please refrain from reorganising things here without prior discussion.
Diffstat (limited to 'community/gsoc/project_ideas/valgrind.mdwn')
-rw-r--r--community/gsoc/project_ideas/valgrind.mdwn81
1 files changed, 81 insertions, 0 deletions
diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn
new file mode 100644
index 00000000..79c8bd1d
--- /dev/null
+++ b/community/gsoc/project_ideas/valgrind.mdwn
@@ -0,0 +1,81 @@
+[[!meta copyright="Copyright © 2009, 2010, 2011 Free Software Foundation,
+Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!meta title="Porting Valgrind to the Hurd"]]
+
+[Valgrind](http://valgrind.org/) is an extremely useful debugging tool for memory errors.
+(And some other kinds of hard-to-find errors too.)
+Aside from being useful for program development in general,
+a Hurd port will help finding out why certain programs segfault on the Hurd,
+although they work on Linux.
+Even more importantly, it will help finding bugs in the Hurd servers themselfs.
+
+To keep track of memory use,
+Valgrind however needs to know how each [[system call]] affects the validity of memory regions.
+This knowledge is highly kernel-specific,
+and thus Valgrind needs to be explicitely ported for every system.
+
+Such a port involves two major steps:
+making Valgrind understand how kernel traps work in general on the system in question;
+and how all the individual kernel calls affect memory.
+The latter step is where most of the work is,
+as the behaviour of each single [[system call]] needs to be described.
+
+Compared to Linux,
+[[microkernel/Mach]] (the microkernel used by the Hurd) has very few kernel traps.
+Almost all [[system call]]s are implemented as [[RPC]]s instead --
+either handled by Mach itself, or by the various [[Hurd servers|hurd/translator]].
+All RPCs use a pair of `mach_msg` invocations:
+one to send a request message, and one to receive a reply.
+However, while all RPCs use the same `mach_msg` trap,
+the actual effect of the call varies greatly depending on which RPC is invoked --
+similar to the `ioctl` call on Linux.
+Each request thus must be handled individually.
+
+Unlike `ioctl`,
+the RPC invocations have explicit type information for the parameters though,
+which can be retrieved from the message header.
+By analyzing the parameters of the RPC reply message,
+Valgrind can know exactly which memory regions are affected by that call,
+even without specific knowledge of the RPC in question.
+Thus implementing a general parser for the reply messages
+will already give Valgrind a fairly good approximation of memory validity --
+without having to specify the exact semantic of each RPC by hand.
+
+While this should make Valgrind quite usable on the Hurd already, it's not perfect:
+some RPCs might return a buffer that is only partially filled with valid data;
+or some reply parameters might be optional,
+and only contain valid data under certain conditions.
+Such specific semantics can't be deduced from the message headers alone.
+Thus for a complete port,
+it will still be necessary to go through the list of all known RPCs,
+and implement special handling in Valgrind for those RPCs that need it.
+
+The goal of this task is at minimum to make Valgrind grok Mach traps,
+and to implement the generic RPC handler.
+Ideally, specific handling for RPCs needing it should also be implemented.
+
+Completing this project will require digging into Valgrind's handling of [[system call]]s,
+and into Hurd RPCs.
+It is not an easy task, but a fairly predictable one --
+there shouldn't be any unexpected difficulties,
+and no major design work is necessary.
+It doesn't require any specific previous knowledge:
+only good programming skills in general.
+On the other hand,
+the student will obtain a good understanding of Hurd RPCs while working on this task,
+and thus perfect qualifications for Hurd development in general :-)
+
+Possible mentors: Samuel Thibault (youpi)
+
+Exercise: As a starter,
+students can try to teach valgrind a couple of Linux ioctls,
+as this will make them learn how to use the read/write primitives of valgrind.