On Thu, Apr 20, 2006 at 01:12:50PM +0200, Christoph Martin wrote: > Hi Kurt, > > Kurt Roeckx schrieb: > > > What it's doing is adding uninitialised numbers to the pool to > > create random numbers. > > > > I've been thinking about commenting those out. > > > > I've been told that using VALGRIND_MAKE_READABLE can be used to > > suppress those errors. So I've been pondering about building the > > library with that. I haven't tried that this works yet though. > > > > Martin, what do you think about this? > > I am not completely shure about what this will do, but would it be > possible to only enable this for the -dbg libraries?
The -dbg package is just stripped out debug symbols moved to a different file/package. Installing the debug package doesn't change the normal library, it's just that the debugger can know found the debug symbols. The library just has a special header saying where the debug symbols are. Let's quote the valgrind manual: 2.7. The Client Request mechanism Valgrind has a trapdoor mechanism via which the client program can pass all manner of requests and queries to Valgrind and the current tool. Internally, this is used extensively to make malloc, free, etc, work, although you don't see that. For your convenience, a subset of these so-called client requests is provided to allow you to tell Valgrind facts about the behaviour of your program, and also to make queries. In particular, your program can tell Valgrind about changes in memory range permissions that Valgrind would not otherwise know about, and so allows clients to get Valgrind to do arbitrary custom checks. Clients need to include a header file to make this work. Which header file depends on which client requests you use. Some client requests are handled by the core, and are defined in the header file valgrind/valgrind.h. Tool-specific header files are named after the tool, e.g. valgrind/memcheck.h. All header files can be found in the include/valgrind directory of wherever Valgrind was installed. The macros in these header files have the magical property that they generate code in-line which Valgrind can spot. However, the code does nothing when not run on Valgrind, so you are not forced to run your program under Valgrind just because you use the macros in this file. Also, you are not required to link your program with any extra supporting libraries. The code left in your binary has negligible performance impact: on x86, amd64 and ppc32, the overhead is 6 simple integer instructions and is probably undetectable except in tight loops. However, if you really wish to compile out the client requests, you can compile with -DNVALGRIND (analogous to -DNDEBUG's effect on assert()). You are encouraged to copy the valgrind/*.h headers into your project's include directory, so your program doesn't have a compile-time dependency on Valgrind being installed. The Valgrind headers, unlike the rest of the code, are under a BSD-style license so you may include them without worrying about license incompatibility. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
