Re: overloading symbols in glibc-2.2.3

[Artie Gold <agold at bga dot com>]

Urs Thuermann wrote:
> 
> A year ago I wrote a small wrapper for gettimeofday() to add a
> constant time offset.  I did this as follows
> 
>     int gettimeofday(struct timeval *tv, struct timezone *tz)
>     {
>         if (__gettimeofday(tv, tz) < 0)
>             return -1;
>         tv->tv_sec += warp;
>         return 0;
>     }
> 
> This works, because
> 
>     $ nm /lib/libc.so.6 |grep gettimeofday
>     0009b170 T __gettimeofday
>     0009b170 W gettimeofday
> 
> Now I wanted to do the same with uname() but there seems not to be an
> __uname() I can call, since that is not a global symbol:
> 
>     $ nm /lib/libc.so.6 |grep uname
>     000a6330 t __uname
>     000a6330 W uname
> 
> And there are other syscalls, where both symbols (with and without the
> __) are weak and global and where there is an additional symbol
> prefixed by __libc_:
> 
>     $ nm /lib/libc.so.6 |egrep -w "(__|__libc_)?(open|read|close)"|sort
>     000c3ea0 T __libc_open
>     000c3ea0 W __open
>     000c3ea0 W open
>     000c3f20 T __libc_close
>     000c3f20 W __close
>     000c3f20 W close
>     000c3f60 T __libc_read
>     000c3f60 W __read
>     000c3f60 W read
> 
> For time() and stime() however there is only one strong and global
> symbol:
> 
>     $ nm /lib/libc.so.6 |egrep -w "stime|time"
>     0009d2c0 T stime
>     0009b120 T time
> 
> What is the reason for these differences?  Is that intended?  I
> thought the main purpose of a weak symbols is that they can be
> overridden in my application without the linker generating an
> "multiple defined symbol" error message.  And the purpose of having
> the __ prefixed symbols is that I can access the original function
> that I have overridden, like I have done with gettimeofday() above.
> But what is then the purpose of a local symbol like __uname() which I
> can't access?
> 
> Another question: I have tried to override time() as I have done with
> gettimeofday() in the example above.  To my surprise it works, even
> from a shared object loaded with LD_PRELOAD, although the time() in
> glibc is not weak.  Why are weak symbols then needed?
> 
> urs

Since no one seems to have responded, I'll take a stab at it (and lend a
possible solution) -- and probably be corrected if I step on myself.

What you recall about using weak symbols to avoid `multiply defined
symbol' errors has to do with static linking as opposed to linking to a
shared object. That's why what you thought shouldn't work, did.

As far as the `__' symbols are concerned, I've run into the same problem
-- made worse by the fact the nature of what I was working on required
me to interpose on any libc system call wrapper that takes a pointer
argument (and deal with intra-libc calls, which usually use the `__'
form, as well). I had no choice but to build a new libc, making all
those symbols visible by tweaking the version scripts in the source
tree.

Fortunately, for what you're doing, you need not do anything so drastic.
All you have to do for uname is the following:

#include <sys/utsname.h>
#include <dlfcn.h> /* for the dynamic loading interface */

int uname(struct utsname * buf) {
   static int (*real_uname)(struct utsname) = NULL;
   if ( ! real_uname ) {
      real_uname = dlsym( RTLD_NEXT, "uname" );
      if ( ! real_uname ) {
         /* something's broken, take appropriate action */
         puts( "symbol uname not found" );
         exit( EXIT_FAILURE );
      }
   }
   { 
      int return_val = real_uname( buf );
      if ( ! return_val ) {
         /* do whatever you need to `buf', filled in by uname */
      }
      return return_val;
   }
}

and link with `-ldl' (to link the dynamic library interface).

You can take a similar approach for other functions.

HTH,
--ag
-- 
Artie Gold, Austin, TX  (finger the cs.utexas.edu account for more info)
mailto:agold@bga.com or mailto:agold@cs.utexas.edu
--
I am looking for work. Contact me.