Building library interposers for fun and profit

April 11, 2001, 1:50 PM —

Summary: Library interposition is a useful technique for tuning performance, collecting runtime statistics, or debugging applications. This article offers helpful tips and tools for working with the technique and gets you started on your own interposer.

Most of today's applications use shared libraries and dynamic linking, especially for such system libraries as the standard C library (libc), or the X Window or OpenGL libraries. Operating system vendors encourage this method because it provides many advantages.

With dynamic linking, you can intercept any function call that an application makes to any shared library. Once you intercept it, you can do whatever you want in that function, as well as call the real function that the application originally intended to call.

Performance tuning is one use of this technology. Even if you have access to profilers and other development tools, or the application's source code itself, having your own library interposer puts you completely in control. You can see exactly what you're doing and make adjustments at any time.

Building and running your first interposer

To use library interposition, you need to create a special shared library and set the LD_PRELOAD environment variable. When LD_PRELOAD is set, the dynamic linker will use the specified library before any other when it searches for shared libraries.

Let's create a simple interposer for malloc(), which is normally a part of /usr/lib/libc.so.1, the standard C library. A message, displaying the argument passed to each malloc() call, will be printed out each time the application calls malloc().

Here's the source for this interposer:


malloc_interposer.c


In the above example, func is a function pointer to the real malloc() routine, which is in /usr/lib/libc.so.1. The RTLD_NEXT argument passed to dlsym(3X) tells the dynamic linker to find the next reference to the specified function, using the normal dynamic linker search sequence.

Now let's build and run this interposer, using ls(1) as our sample application. We'll use the C-shell syntax for this and other examples.

% cc -o malloc_interposer.so -G -Kpic malloc_interposer.c
% setenv LD_PRELOAD $cwd/malloc_interposer.so
% ls -l malloc_interposer.so
malloc(64) is called
malloc(52) is called
malloc(1072) is called
-rwxr-xr-x   1 gregn        5224 Aug  3 15:21 malloc_interposer.so*
% unsetenv LD_PRELOAD

Without access to the source code of ls(1), and without rebuilding it in any way, we've just discovered which arguments the application used to call malloc() in the test run.

Note that LD_PRELOAD must specify the full path to the interposer library, and that library interposition is disabled for setuid programs in order to prevent security problems.

Collecting runtime statistics

Here's a more practical example of library interposition on malloc(), as well as on a few other routines. It collects statistics about the size of the memory blocks requested with the calls to malloc(), calloc(), and realloc(), and prints out a histogram detailing their use upon exiting the application.

Here's the source code:

malloc_hist.c

Note that we round up all memory-request sizes to the next power of two. To obtain the name of the current executable, we use the proc(4) interface. The version of the proc(4) interface used here works with Solaris 2.6 and above.