mirror of
https://github.com/ioacademy-jikim/debugging
synced 2025-06-08 08:26:14 +00:00
70 lines
3.1 KiB
Plaintext
70 lines
3.1 KiB
Plaintext
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
|
|
|