From: Nicholas Nethercote Date: Mon, 15 Dec 2008 21:29:29 +0000 (+0000) Subject: Add some useful info. X-Git-Tag: svn/VALGRIND_3_4_0~70 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=aee8de836747aef1641250f8b62deffa22a66d95;p=thirdparty%2Fvalgrind.git 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 index 0000000000..609aacbd59 --- /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 +To: Igor Shaul +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" 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 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 +