Bug#363516: [Pkg-openssl-devel] Bug#363516: valgrind-clean the RNG

[Kurt Roeckx]

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