Re: tools for shared object manipulation

John writes:
> [For a project a couple of years ago I whipped up some programs to rename
> symbols in SunOS shared libraries so we could plug in some debugging wrappers.
> (It was for an early version of what is now Segue's QA Partner.) It wasn't
> hard to do, only took me an afternoon to get it to work. -John]


This is a useful thing to do, but for those people who don't actually like
grubbing around in the depths of the ELF file format on SunOS 5.x, the
dynamic linker will actually do this for you. Consider the following
file, malloc.c:


#include <sys/types.h>
#include <dlfcn.h>
#include <stdio.h>


void *
malloc(size_t size)
{
static void *(*fptr)() = 0;
char buffer[100];


if (fptr == 0) {
fptr = (void *(*)())dlsym(RTLD_NEXT, "malloc");
if (fptr == NULL) {
(void) sprintf(buffer, "dlopen: %s\n", dlerror());
write(2,buffer,strlen(buffer));
return NULL;
}
}
(void) sprintf(buffer, "malloc: %#x bytes\n", size);
(void) write(1, buffer, strlen(buffer));
return (*fptr)(size);
}


The file defines a wrapper for malloc(), which obtains a pointer to
the next version of malloc() defined in the chain of loaded shared
objects (which is normally the one in libc). The wrapper uses this
pointer to invoke the normal malloc services.


This can be compiled to produce a new shared object:


$ cc -o malloc.so.1 -G -K pic malloc.c


Any dynamically-linked program "prog" can then have this wrapper version
of malloc() included, just by setting LD_PRELOAD first, eg:


$ LD_PRELOAD=./malloc.so.1 prog
malloc: 3f bytes


This is all explained in "SunOS 5.3 Linker and Libraries Manual",
Chapter 3, "Obtaining new symbols".


There are quite a lot of possible uses for this technique (whether
implemented as above, or through tools to mung symbol tables). A list
I came up with recently includes:
New namespace controls:
All the calls which accept pathnames as arguments are faked,
and replaced by ones which connect to a daemon. The daemon
maintains a model of a namespace which effects different
semantics from the NFS or UFS ones. For example, Plan 9
bindings.
Library migration:
If an old call has been replaced by a new one, the call can
be faked, to record whether tools are still using it. How we
get the tool's name might be awkward, though.
database file interface:
This is just a variant on the namespace idea, but it means
that normal programs could access a database (or any server)
directly (albeit slowly) without any modification.
Statistics gathering:
To profile a program, to determine which functions it's calling,
and with what kinds of arguments (prof et al. won't tell you
the last bit).
Removal of name clashes:
Possibly quite handy in the case of third-party libraries which
have used the same name.
Debugging:
Just to let you know that you're calling the system libraries
with the correct arguments.
RPC generation:
Instead of calling a function locally, an RPC-based wrapper
could be provided which calls another daemon.
Error handling checking:
Could be used to force library functions to "fail" at particular
moments, in order to force execution of the handling code for
such errors. This could be used to effectively provide 100%
code coverage for application testing.


In response to the original poster, the dlopen(), etc. functions may do
what you want for adding, extracting, etc., and the SunOS 5.3 dynamic
linker accepts the environmental variable LD_DEBUG, which provides a lot
of information about what's going on. Try:


$ LD_DEBUG=help who


steve
--
<Steve_Kilbane@cegelecproj.co.uk>
--

Return to the comp.compilers page.
Search the comp.compilers archives again.