Re: Dynamic linker refactoring

[Rich Felker <dalias@aerifal.cx>]

On Sat, Jan 21, 2012 at 01:19:40PM +0100, aep wrote:
> On Fri, 20 Jan 2012 20:05:54 -0500, Rich Felker wrote:
> >Hi all,
> >
> > I'm leaning towards stripping out the vdso
> >(linux-gate) support at the dynamic linker level entirely, and
> >instead
> >using Nik's original design for vdso-assisted clock_gettime which can
> >work with static linking too.
> 
> isn't the vdso there for much more then just clock_gettime? Ie for a
> whole bunch of syscalls that otherwise need to go through the slow
> interrupt path?

I wouldn't say a whole bunch. At present there are only one or two
other functions provided by vdso and their applicability is so limited
I can't see them benefitting anything. Certainly there is a fair bit
more that could be implemented by the kernel in userspace in the
future, though.

What I originally thought was useful, but now I'm rethinking, is the
practice of actually including the vdso as a dso in the main chain of
loaded dsos, where its symbols become globally visible (including
accessible by the application using dlsym, for example). In principle,
it could replace symbols from the libc with its own versions. The fact
that I ordered it after libc rather than before partly ameliorates
this problem, but if the symbol in libc is weak, it can still be
overridden by a strong symbol in the vdso. (In fact this is how
__vdso_clock_gettime currently works!) If used correctly, it's no big
deal, but it would be quite unfortunate if the kernel developers went
and added some override that was intended to work with glibc but broke
horribly with musl..

Anyway with that in mind, I'd thought about at least 2 possible
alternatives:

1. Load the vdso through the dynamic linker code, but don't insert it
in the dso list, and instead search out the symbols we want from it
directly.

2. Include the vdso-linking code directly in the functions (like
clock_gettime) that might want vdso code.

Option 2 has the advantage of working even with static linking, but in
the immediate it would cause more code duplication. In the long term,
on the other hand, it might lead to better code factoring by allowing
us to move some of the hash, symbol table search, etc. code out of
dynlink.c and into a module that could be reused both for the vdso
search in static binaries and by the dynamic linker.

Rich