Re: ppc64 vDSO in mainline

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

> Yes if the vdso64.so has .odp entries then vdso64.so must avoid exporting 
> any relocations against its .opd. Either the vdso64.so can be bound at a 
> static address (which allows the .opd entry contents to be resolved at 
> link time). Or the kernel must perform any required relocations in the 
> vdso and must remove those relocations from ELF header before it is made 
> visible to ld.so.

The vDSO doesn't have .opd and won't have. The kernel can't perform any
relocation as the vDSO will be virtually mapped at different addresses.
It is not the case now but will be once I enable randomization.

> You linked the vdso to a static address so it is the actual address. 
> Anyway the dynmaic linkers symbol resolutions should do any required 
> arthimatic. 

The vDSO is linked to 0 and mapped at 1Mb with the current
implementation. It doesn't expose OPDs so you can't call vDSO functions
from a test executable without an asm glue on ppc64. ppc32 is easier to
deal with in this regard :)

> See my comment above. I agreed to removing the .opd to get around a 
> problem in the short term. Now we are discussing design which should be 
> looking long term.

Well, it's done and in mainline, so we'll have to deal with it now. 

> Like I mentioned about there are reasons why the vdso will need the TOC 
> pointer set. Even static leaf routines can use the TOC to access large 
> constants and there is the issues of how gettimeofday accesses the magic 
> timer conversation values (which change periodically).

This has been implemented without a TOC. It's there, look at the code.
It might be possible to change that in the future, however I yet have to
figure out how to pass a TOC pointer to ld.so to put in the .opd's.
Again, these can't be fixed up by the kernel unless we give up on the
possibility to have the vDSO ever be elsewhere than a fixed address,
identical in every process.