|
From: Torsten L. <t.l...@pr...> - 2004-05-07 18:24:17
|
Hi, (Following: Background - skip if in a hurry :-) in the FAQ I found the possibility of linking one's application to the valgrind .o files to receive an application that always runs under valgrind control, which I find very interesting. It worked (somehow) for me with valgrind-2.0.0. I had to remove the vg_pthread object files because I got errors of undefined refs to errno and h_errno. The other problem was an undefined ref to vgPlain_cplus_demangle in vg_demangle.o which I side-stepped by commenting the references out (my code is C, not C++, and doesn't use threads, so I'm ok). Not the best solution, though. I couldn't get it done with valgrind-2.1.1, btw. (Real question for the impatient) Would it be possible to create a "libvalgrind.a" or something which enables one to create always-valgrinded binaries, with thread support and C++ demangling and everything? Possibly with a good default config compiled in, so I don't have to set VG_ARGS before every run? I'd love to see that. I could link my daemons (apache, exim, ...) and my applications to it and collect the reports once in a while, making the world a better (or at least less bug-ridden) place for everyone :-) Greetings, Torsten <t.l...@pr...> |
|
From: Nicholas N. <nj...@ca...> - 2004-05-07 22:16:46
|
On Fri, 7 May 2004, Torsten Luettgert wrote:
> Would it be possible to create a "libvalgrind.a" or something which
> enables one to create always-valgrinded binaries, with thread support
> and C++ demangling and everything? Possibly with a good default config
> compiled in, so I don't have to set VG_ARGS before every run?
> I'd love to see that.
The way Valgrind starts up changed fundamentally between 2.1.0 and 2.1.1.
In 2.1.0 and earlier, Valgrind was a shared object (valgrind.so), and
LD_PRELOAD was set to include valgrind.so. When valgrind.so's .init
section was run, Valgrind grabbed control. valgrind.so was linked with a
flag that says "please initialise me first" so that it could grab control
as early as possible. This was simple, but had three big problems:
- it didn't work with statically linked binaries
- some code ran before Valgrind gained control, which was a bit dodgy,
and there were some hacks in place to deal with this
- Valgrind couldn't use any libraries (eg. glibc) used by the client
program.
The new method in 2.1.1 is this: Valgrind actually loads itself and the
client program on its own in a two-stage bootstrap process. As a result,
Valgrind has control before the client executes its first instruction, and
the problems above are avoided.
However, as a consequence, I don't think the libvalgrind.a idea will
work; for example, Valgrind now has a main() function. I might be wrong,
though.
> I could link my daemons (apache, exim, ...) and my applications
> to it and collect the reports once in a while, making the world a better
> (or at least less bug-ridden) place for everyone :-)
Why do you need to permanently link Valgrind with these programs? Is it
too difficult to prefix the commands with "valgrind --tool=..."?
N
|