This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Wrapping versioned glibc symbol
Hi Mike,
Thanks for the reply! However I was asking slightly different
questions. I rephrase them below:
1 For some functions glibc provides underscored versions (like
__pthread_mutex_lock() as an alias for pthread_mutex_lock()
(actually vice versa I guess). When I want to provide by own
version of this function, while calling the original one, should I
call __pthread_mutex_lock() directly, or use dlsym(XXX,
"pthread_mutex_lock"). Dynamic linking is assumed. What is the
Best Current Practice? Actually now I think I should use dlsym(),
as it allows for cascading wrappers (though I've seen quite a few
examples of calling underscored version before).
2 For some functions (mostly versioned ones) glibc doesn't provide
underscored variant. Is there a way to call versioned function not
using dlsym()? (This is what I ambiguously called "the static way".)
3 When using dlsym(), manual page made me think that the correct way
would be dlsym(RTLD_NEXT, "pthread_cond_signal"). However the
program below (which is a stripped-down version of the program from
my previous post, and which I advise to actually run ;), shows that
RTLD_NEXT works counter-intuitive: it doesn't bind to the
default/latest version of pthread_cond_signal() in glibc:
/*
nm /lib/libpthread.so.0 | grep '\bpthread_cond_signal\b'
gcc -pthread test2.c -o test2 -ldl
./test2
*/
#define _GNU_SOURCE
#include <dlfcn.h>
#include <pthread.h>
#include <execinfo.h>
static int (*__pthread_cond_signal)(pthread_cond_t *cond);
int
pthread_cond_signal(pthread_cond_t *cond)
{
return __pthread_cond_signal(cond);
}
int
main()
{
void *addr;
__pthread_cond_signal = dlsym(RTLD_NEXT, "pthread_cond_signal");
addr = (void *)__pthread_cond_signal;
backtrace_symbols_fd(&addr, 1, 1);
}
I tried it on glibc 2.6, 2.8, 2.9, it gives
$ nm /lib/libpthread.so.0 | grep '\bpthread_cond_signal\b'
00d196a0 T pthread_cond_signal@@GLIBC_2.3.2
00d19950 T pthread_cond_signal@GLIBC_2.0
./test2
/lib/libpthread.so.0(pthread_cond_signal+0x0)[0xd19950]
As you can see, [0xd19950] is the address of @GLIBC_2.0, not
@@GLIBC_2.3.2, which I think it should be. Do you observe different
results?
--
Tomash Brechko