Re: ppc64 vDSO in mainline

[Roland McGrath <roland at redhat dot com>]

> Case 1) Do you object to part of libc (in platform specific code) using 
> PLT linkage to VDSO functions? 

No, that's the optimal solution we're trying to get to.  I have said that
it's a hairy proposition and the more straightforward suboptimal hacks are
what you should do first.

> Would link time (ld) binding to the vdso??.so be acceptable in this case?

Not any time soon.  You need to cope with kernels that don't have a vdso
with what you need.  That being the case, I won't even go into the compile
time hassles of wanting to do this.

> Case 2) Would Add-ons be an acceptable venue for exporting functions like 
> the dcache/icache flush routine as Ben has suggested?

I can't tell what you think you mean here.

> 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)? 

I never said I had any objection to doing this case optimally (though I
have repeatedly said it should be done suboptimally first).  All I've said
is that the glibc ABI is the glibc ABI, and we don't delegate specification
of parts of it to something else like the vDSO.  If the vDSO contains
functions matching the signatures of glibc ABI entry points, then it's an
implementation detail in glibc's domain if it decides to resolve user PLT
entries directly to the vDSO entry point.  

> 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?

This is all quite vague.  If you are proposing a particular feature, then
you need to be more specific about exactly what it does and how.  Obviously
what's needed for the general-purpose optimal solution is a means to say
that one DSO's versioned symbols can be satisfied by another DSO's
definitions.  DT_AUXILIARY is for this sort of thing, but I am not at all
sure how it works in our dynamic linker at the moment and especially in
relation to version set matching.  


Thanks,
Roland