This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]