Add some useful info.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8827

diff --git a/docs/internals/why-no-libc.txt b/docs/internals/why-no-libc.txt
new file mode 100644 (file)
index 0000000..609aacb
--- /dev/null
+++ b/docs/internals/why-no-libc.txt
@@ -0,0 +1,69 @@
+ate: Mon, 15 Dec 2008 15:23:31 -0500
+From: Stephen McCamant <smcc@CSAIL.MIT.EDU>
+To: Igor Shaul <mindmaze@gmail.com>
+Cc: valgrind-developers@lists.sourceforge.net
+Subject: Re: [Valgrind-developers] Using standard C library in valgrind tool
+
+RW> On Dec 12, 2008, at 6:33 PM, "Igor Shaul" <mindmaze@gmail.com> wrote:
+
+IS> Hi,
+IS> I would like to write a valgrind tool that uses the standard c
+IS> library (actually, I must link my tool to another library, which
+IS> happens to use stdlib). I noticed that all the tools link with -
+IS> nodefaultlibs flag, and if said flag is removed, then naturally no
+IS> main() is found (stdlib requires a main). So, is there a natural
+IS> way to use stdlib in my valgrind tool?
+
+>>>>> "RW" == Robert Walsh <rjwalsh@durables.org> writes:
+
+RW> Sadly, no. Valgrind shares the address space of the guest process,
+RW> which would mean libc would get linked into the address space
+RW> twice.  There's no telling how libc would react to that.
+
+Though I agree that the short answer is "sorry, that's not supported",
+I thought you might find a few more technical details helpful in
+considering what to do.
+
+Valgrind tools and the guest processes do run in the same address
+space in terms of memory management, but in current versions they
+don't share any dynamic linker context, and in fact Valgrind tools
+don't link with libc at all, so there wouldn't be a double-linking
+problem per se.
+
+However, there are some incompatibilities between Valgrind and glibc
+that are the reason Valgrind tools don't link with the standard
+libraries. The most fundamental one is that Valgrind and glibc are
+both designed with the assumption that they alone will be talking to
+the kernel on behalf of their process, but obviously this can't be
+true for both at once.
+
+As of a few years ago, it was still possible (though unsupported) to
+just link your tool directly with /usr/lib/libc.a, and it worked for
+at least a reasonable subset of programs and glibc functionality. I
+research tool I was working on did that for a while. However, we gave
+that up because of a further issue that affects glibcs configured with
+thread-local storage (which I think is standard these days). Glibc now
+uses a segment pointed to by %gs to keep TLS, other thread data,
+-fstack-protector canary values, and who knows what else. It relies on
+its startup code to initialize this correctly, so if you call many
+glibc functions before initializing this, it crashes. That's the point
+where we gave up.
+
+In theory, I don't think any of these Valgrind/glibc incompatibilities
+are fundamental, and there would be ways of hacking around them. But
+the glibc and Valgrind developers don't consider them bugs, and so
+probably aren't interesting it expending much effort to fix them.
+
+So if you need C standard library functionality that isn't covered by
+the Valgrind core's somewhat non-standard subset, you'll have to get
+it from somewhere else. What we found to be the easiest approach in
+our Fjalar tool was to cut and paste the particular functions we need
+from dietlibc (a nice lightweight implementation) or glibc itself. The
+code is GPLed if you want to reuse it.
+
+http://groups.csail.mit.edu/pag/fjalar/
+
+Hope this helps,
+
+ -- Stephen
+