This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: kernel DSO
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.