Re: overriding __ functions

[Geoff Keating <geoffk@ozemail.com.au>]

> Date: Thu, 3 Dec 1998 14:18:52 +0100 (MET)
> From: Mark Kettenis <kettenis@wins.uva.nl>

>    Date: Thu, 3 Dec 1998 05:10:52 -0500 (EST)
>    From: baccala@FreeSoft.org
> 
>    Both forms should be supported.  My programs work by overloading
>    the system calls, expecting to grab everything that calls open(),
>    be it the user program or glibc.

I kind of agree with this.  It's certainly a useful sort of thing to
do.

Of course, this sort of overriding can never be portable.  Even if you
override open(), one day the kernel may add a new way to open files.
This happened with chown() and lchown(), for instance.  So you
shouldn't expect your library will work with different versions of
glibc.  In any case, you'll probably want to override all versions of
the symbol, and the versions may grow with every glibc release.

Also, types may vary between the kernel and the libc.

...
> Therefore this might be an argument for the case that, if foo() is
> nothing but an alias for __foo(), glibc should export both foo() and
> __foo(), and should continue to do so in the future.

One disadvantage of this is that the ability to override such
functions is not without cost; glibc must use a PLT entry every time
it calls the function.  I guess that for syscalls the relative
overhead is not large.

Another disadvantage is that user programs will then start using
__foo; by mistake, presumably, but that won't help if __foo goes
away.  That was one of the big advantages of symbol versioning, it
made this impossible.

Hmmm.  Here's a thought.  Would it be possible to get the kernel to
intercept the syscalls as they were made?  After all, the kernel is
the first single point that all syscalls must go through.

Another possibility, but which is machine-dependent, is to search
through the glibc binary looking for the syscall sequence, then
replace it with a jump.  Evil, but it will work.

A third possibility is to build your library into a special version of
glibc; then all you need to do is set LD_LIBRARY_PATH.  After all,
isn't this what the LGPL is all about?

-- 
Geoffrey Keating <geoffk@ozemail.com.au>