Dynamic linker refactoring

Dynamic linker refactoring

[Rich Felker]

Hi all,

After the recent dynamic linker fixes, I've looked into refactoring
(mainly eliminating logic duplication) and cleaning up the dynamic
linker. As a heads-up, 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. This cuts out some complexity and code
duplication in the dynamic linker (at the expense of duplicating the
same code elsewhere for use outside the dynamic linker), but the real
benefit is that we don't have to worry about the kernel devs doing
something stupid and polluting the userspace symbol namespace (and
potentially redirecting functions to do the wrong thing) if they add
stuff to the vdso that doesn't belong there. If anyone's against these
changes or wants to discuss them more, please reply in this thread in
the next day or so..

Rich

Re: Dynamic linker refactoring

[aep]

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?

Re: Dynamic linker refactoring

[Rich Felker]

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

Re: Dynamic linker refactoring

[aep]

Ah now i see what you're doing there, thanks for the explanation.

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

Perfect. I like the kernel-code-in-userspace hack, but doing it through 
a dso seemed not very well thought out.
Your idea sounds a lot cleaner.