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