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

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

Using and understanding the Valgrind core: Advanced Topics
compiling to a
.o
and linking it in, or compiling to a
.so
and
LD_PRELOAD
ing it in. The latter is more convenient
in that it doesn’t require relinking.
All wrappers have approximately the above form. There are three crucial macros:
I_WRAP_SONAME_FNNAME_ZU
: this generates the real name of the wrapper. This is an encoded name which
Valgrind notices when reading symbol table information. What it says is: I am the wrapper for any function named
foo
which is found in an ELF shared object with an empty ("
NONE
") soname field. The specification mechanism is
powerful in that wildcards are allowed for both sonames and function names. The details are discussed below.
VALGRIND_GET_ORIG_FN
: once in the the wrapper, the first priority is to get hold of the address of the original
(and any other supporting information needed). This is stored in a value of opaque type
OrigFn
. The information is
acquired using
VALGRIND_GET_ORIG_FN
. It is crucial to make this macro call before calling any other wrapped
function in the same thread.
CALL_FN_W_WW
: eventually we will want to call the function being wrapped. Calling it directly does not work, since
that just gets us back to the wrapper and leads to an infinite loop. Instead, the result lvalue,
OrigFn
and arguments
are handed to one of a family of macros of the form
CALL_FN_*
. These cause Valgrind to call the original and avoid
recursion back to the wrapper.
3.3.2. Wrapping Specifications
This scheme has the advantage of being self-contained. A library of wrappers can be compiled to object code in the
normal way, and does not rely on an external script telling Valgrind which wrappers pertain to which originals.
Each wrapper has a name which, in the most general case says: I am the wrapper for any function whose name matches
FNPATT and whose ELF "soname" matches SOPATT. Both FNPATT and SOPATT may contain wildcards (asterisks)
and other characters (spaces, dots, @, etc) which are not generally regarded as valid C identifier names.
This flexibility is needed to write robust wrappers for POSIX pthread functions, where typically we are not completely
sure of either the function name or the soname, or alternatively we want to wrap a whole set of functions at once.
For example,
pthread_create
in GNU libpthread is usually a versioned symbol - one whose name ends in, eg,
@GLIBC_2.3
. Hence we are not sure what its real name is. We also want to cover any soname of the form
libpthread.so* . So the header of the wrapper will be
int I_WRAP_SONAME_FNNAME_ZZ(libpthreadZdsoZd0,pthreadZucreateZAZa)
( ... formals ... )
{ ... body ... }
In order to write unusual characters as valid C function names, a Z-encoding scheme is used. Names are written
literally, except that a capital Z acts as an escape character, with the following encoding:
46