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

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

Using and understanding the Valgrind core: Advanced Topics
Za encodes
*
Zp +
Zc :
Zd .
Zu _
Zh -
Zs (space)
ZA @
ZZ Z
ZL ( # only in valgrind 3.3.0 and later
ZR ) # only in valgrind 3.3.0 and later
Hence
libpthreadZdsoZd0
is an encoding of the soname
libpthread.so.0
and
pthreadZucreateZAZa
is an encoding of the function name
pthread_create@*
.
The macro I_WRAP_SONAME_FNNAME_ZZ constructs a wrapper name in which both the soname (first component)
and function name (second component) are Z-encoded. Encoding the function name can be tiresome and is often
unnecessary, so a second macro,
I_WRAP_SONAME_FNNAME_ZU
, can be used instead. The
_ZU
variant is also
useful for writing wrappers for C++ functions, in which the function name is usually already mangled using some
other convention in which Z plays an important role. Having to encode a second time quickly becomes confusing.
Since the function name field may contain wildcards, it can be anything, including just
*
. The same is true for
the soname. However, some ELF objects - specifically, main executables - do not have sonames. Any object
lacking a soname is treated as if its soname was
NONE
, which is why the original example above had a name
I_WRAP_SONAME_FNNAME_ZU(NONE,foo)
.
Note that the soname of an ELF object is not the same as its file name, although it is often similar. You can find the
soname of an object
libfoo.so
using the command
readelf -a libfoo.so | grep soname
.
3.3.3. Wrapping Semantics
The ability for a wrapper to replace an infinite family of functions is powerful but brings complications in situations
where ELF objects appear and disappear (are dlopen’d and dlclose’d) on the fly. Valgrind tries to maintain sensible
behaviour in such situations.
For example, suppose a process has dlopened (an ELF object with soname)
object1.so
, which contains
function1
. It starts to use
function1
immediately.
After a while it dlopens
wrappers.so
, which contains a wrapper for
function1
in (soname)
object1.so
. All
subsequent calls to
function1
are rerouted to the wrapper.
If
wrappers.so
is later dlclose’d, calls to
function1
are naturally routed back to the original.
Alternatively, if
object1.so
is dlclose’d but
wrappers.so
remains, then the wrapper exported by
wrappers.so
becomes inactive, since there is no way to get to it - there is no original to call any more.
However, Valgrind remembers that the wrapper is still present. If
object1.so
is eventually dlopen’d again, the
wrapper will become active again.
In short, valgrind inspects all code loading/unloading events to ensure that the set of currently active wrappers remains
consistent.
47