Re: Wrapping versioned glibc symbol

[Tomash Brechko <tomash dot brechko at gmail dot com>]

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