This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: ppc64 vDSO in mainline
- From: Roland McGrath <roland at redhat dot com>
- To: Steve Munroe <sjmunroe at us dot ibm dot com>
- Cc: Alan Modra <amodra at bigpond dot net dot au>,Benjamin Herrenschmidt <benh at kernel dot crashing dot org>,libc-alpha at sources dot redhat dot com
- Date: Mon, 28 Mar 2005 12:57:38 -0800
- Subject: Re: ppc64 vDSO in mainline
> There remains to issue of what does libc link to generate the PLT enties.
> The simpliest solution it is link to the vdso??.so for each plaform. But
> there may be more elegant solutions. VDSO also becomes part of the ABI for
> each platform and has to be managed and versioned.
That's exactly what we don't want. The glibc sources are what define the
ABI for normal applications. End of story.
This is why there is a generic dynamic linker complication in wanting to do
things the optimal way when you have a kernel vDSO providing an entry point
that matches the user ABI. It's the same issue if you want to have a
subsidiary library (DT_NEEDED) define one of your entry points and not pay
the penalty of having a stub that jumps to it. Versioned symbols are
really a triple of soname, set name, symbol name. The ABI symbol is e.g.
libc.so.6:GLIBC_2.2:gettimeofday. If the definition of this is going to
come from an object not called libc.so.6, some new dynamic linker magic is
required to arrange this kind of symbol resolution.