kernel DSO

[Benjamin Herrenschmidt]

On Wed, 2004-09-15 at 13:56, Richard Henderson wrote:
> On Tue, Sep 14, 2004 at 09:03:28AM +0200, Jakub Jelinek wrote:
> > One is symbol versioning, glibc suddenly looses control of the symbol
> > versions which the vDSO is overriding, so coming up with a new symbol
> > version for one of these functions is hard.
> 
> One possibility here is the symbol forwarding that Sun invented
> recently.  You'd have the version symbol in libc, and the forward
> would point to the VDSO.  Which adds a tiny bit of extra lookup
> during symbol resolution, but no extra overhead when actually 
> using the symbol.

Interesting...

> > The other is that it badly clashes with prelinking.
> 
> Yes, well...  The only solution here is to force conflicts for
> symbols in the VDSO.  I would support adding this as a feature for
> prelink, so that ppc folk could experiment and see if the tradeoff
> is worth it.

Note that the vDSO, as far as the current code is concerned, will be
almost always at it's "native" address (I don't plan to randomize)
so prelink I suppose would be fine. Only apps specifically asking
for a different location would be affected here.

Which is why I wonder why we don't stick to the simple solution of
having l_relocated set to 0 when l_addr is 0 for the vDSO on ppc64
specifically in dl_main, at least for now. That way, ld.so triggers
a copy on write after mprotect'ing the vdso for doing the actual
fixups of the OPDs, which is supported by my vDSO implementation.

I know Ulrich doesn't like this solution, it's really the simplest
at this point, no ?

Ben.