Re: ppc64 vDSO in mainline

[Benjamin Herrenschmidt <benh at kernel dot crashing dot org>]

> I am trying to understand the design requirements which are not the same 
> as the current implementation.
> 
> I am pressing this issue because the current definition is unnecessary 
> restrictive.  Even with the restrictions you have given (including 
> randomization of VDSO base), I am convinced that powerpc32/powerpc64 can 
> use normal PLT binding for VDSO functions. I also believe this can be 
> extended to the other platforms. This will be a benefit to all.
> 
> It turns out that powerpc32 works as is and powerpc64 should work with 
> unrelocated (but ReadOnly) .opd's (they will be relocated by 
> ld64.so/elf_machine_fixup_plt when copied to the PLT). Using the .got or 
> .toc with the VDSO is slightly more complicated and we can cross that 
> bridge when we come to it.

If you want to experiment with that, I think I left the option to build
the descriptors in the vDSO code (though I haven't tested it for a
while, it might not even build ...). In include/asm-ppc64/vdso.h, turn 

#undef VDS64_HAS_DESCRIPTORS

to

#define VDS64_HAS_DESCRIPTORS

> For gettimeofday a kludgy interface does not matter (much) but as we look 
> at other opportunities for processor specific optimizations the overhead 
> of this interface does matter. A function pointer is slower (~6 cycles) 
> than a direct branch and the powerpc32 PLT fixup will update the PLT with 
> a branch absolute (1 cycle), if the targer is anywhere in the lower 32MB 
> of the address space. On POWER4/5 I can move or compare a lot of bytes in 
> 5 cycles.

But ppc64 will always load pointers from OPDs no ? That is, ppc64 will
always end up using function pointers no ? ppc32 is not a problem, as
you stated, it works as-is and doesn't need descriptors anyway.

> Ok, but as I understand the design requires and trade-offs I will continue 
> to explore alteratives.