docs/internals/why-no-libc.txt - platform/external/valgrind - Git at Google

 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
	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