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