Valgrind Software, Быстрый старт

Страница: 60 / 319

Using and understanding the Valgrind core: Advanced Topics
A second possible problem is that of conflicting wrappers. It is easily possible to load two or more wrappers, both of
which claim to be wrappers for some third function. In such cases Valgrind will complain about conflicting wrappers
when the second one appears, and will honour only the first one.
3.3.4. Debugging
Figuring out what’s going on given the dynamic nature of wrapping can be difficult. The --trace-redir=yes
option makes this possible by showing the complete state of the redirection subsystem after every
mmap
/
munmap
event affecting code (text).
There are two central concepts:
• A "redirection specification" is a binding of a (soname pattern, fnname pattern) pair to a code address. These
bindings are created by writing functions with names made with the I_WRAP_SONAME_FNNAME_{ZZ,_ZU}
macros.
• An "active redirection" is a code-address to code-address binding currently in effect.
The state of the wrapping-and-redirection subsystem comprises a set of specifications and a set of active bindings.
The specifications are acquired/discarded by watching all
mmap
/
munmap
events on code (text) sections. The active
binding set is (conceptually) recomputed from the specifications, and all known symbol names, following any change
to the specification set.
--trace-redir=yes shows the contents of both sets following any such event.
-v
prints a line of text each time an active specification is used for the first time.
Hence for maximum debugging effectiveness you will need to use both options.
One final comment. The function-wrapping facility is closely tied to Valgrind’s ability to replace (redirect) specified
functions, for example to redirect calls to
malloc
to its own implementation. Indeed, a replacement function can be
regarded as a wrapper function which does not call the original. However, to make the implementation more robust,
the two kinds of interception (wrapping vs replacement) are treated differently.
--trace-redir=yes
shows specifications and bindings for both replacement and wrapper functions. To
differentiate the two, replacement bindings are printed using
R->
whereas wraps are printed using
W->
.
3.3.5. Limitations - control flow
For the most part, the function wrapping implementation is robust. The only important caveat is: in a wrapper, get hold
of the
OrigFn
information using
VALGRIND_GET_ORIG_FN
before calling any other wrapped function. Once you
have the OrigFn , arbitrary calls between, recursion between, and longjumps out of wrappers should work correctly.
There is never any interaction between wrapped functions and merely replaced functions (eg malloc ), so you can
call malloc etc safely from within wrappers.
The above comments are true for {x86,amd64,ppc32,arm,mips32,s390}-linux. On ppc64-linux function wrapping is
more fragile due to the (arguably poorly designed) ppc64-linux ABI. This mandates the use of a shadow stack which
tracks entries/exits of both wrapper and replacement functions. This gives two limitations: firstly, longjumping out
of wrappers will rapidly lead to disaster, since the shadow stack will not get correctly cleared.
Secondly, since the
shadow stack has finite size, recursion between wrapper/replacement functions is only possible to a limited depth,
beyond which Valgrind has to abort the run. This depth is currently 16 calls.
For all platforms ({x86,amd64,ppc32,ppc64,arm,mips32,s390}-linux) all the above comments apply on a per-thread
basis. In other words, wrapping is thread-safe: each thread must individually observe the above restrictions, but there
is no need for any kind of inter-thread cooperation.
48