This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: ppc64 vDSO in mainline
- From: Steve Munroe <sjmunroe at us dot ibm dot com>
- To: Roland McGrath <roland at redhat 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 17:10:56 -0600
- Subject: Re: ppc64 vDSO in mainline
Roland McGrath <roland@redhat.com> wrote on 03/28/2005 02:57:38 PM:
> > 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.
>
Ok I understand that, but I would like to separate the cases: 1) a VDSO
interface that is only used within libc (libm, ...). 2) a VDSO interface
that is not a function provided by libc. 3) a function which is currently
exported by libc , but a better optimized version (with a different
symbol) is also exported by the VDSO.
Case 1) Do you object to part of libc (in platform specific code) using
PLT linkage to VDSO functions? Would link time (ld) binding to the
vdso??.so be acceptable in this case?
Case 2) Would Add-ons be an acceptable venue for exporting functions like
the dcache/icache flush routine as Ben has suggested? The for now we can
accept wrappers around the VDSO functions for these functions. Add-ons has
the advantage that the exported function would be available to both libc
and applications. This will also allows us to hide any special binding
that requires access to internal dynamic linker functions or data
structures (like _dl_vsym).
Case 3) I suspect you main objection is specific is this case? Is this an
absolute prohibition or a requirement that what ever happens glibc will
control the ABI (which symbols get exported)?
This question is important to dealing with processor specific
optimizations. The distro's will never be willing to build glibc for all
the various processor micro-architectures that exist now and in the
future. I am looking for compromise here where glibc remains in control of
the ABI but the kernel (who knows exactly what hardware we are running on)
can make available processor specific optimizations.
>
> 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.
>
Ok, what if: The application requested a binding to
libc.so.6:GLIBC_2.2:gettimeofday and the (runtime) link map contained
exports for both libc.so.6:gettimeofday@@GLIBC_2.3 and
[vdso.so]:gettimeofday@@GLIBC_2.3 (this is normal today with
NEED_DL_SYSINFO_DSO, with VDSO's map after libc's)? Futher there was
auxiliary information provided at glibc build/link time that
gettimeofday@@GLIBC_2.3 was a an substitutable symbol (perhaps similar to
the current syscalls.list)? Then _dl_fixup / elf_machine_fixup_plt could
make the substitution in the PLT if; the substitution was permitted, and
the matching symbol and version was available?
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center