Re: ppc64 vDSO in mainline

[Roland McGrath <roland at redhat dot com>]

> Can't libc.so itself link against the vDSO rather than the application ?
> I don't like the idea of requiring _applications_ to link against it.

The vDSO's symbols should never be used directly by any application.
It can be done, put it's just a poor idea.

> Not even the address, unless I did something wrong, but an offset.

If you mean an offset from the beginning of the segment with p_vaddr 0,
then that's what "address" means when we're talking about a DSO symbol.
The symbols in the vDSO ought to be normal symbols for the code addresses,
like they are on descriptorless machines.  That means they are relative to
the load offset of the lowest segment (in this case, the only segment);
i.e. the p_vaddr need not be zero.  If the common case will use a canonical
address for the vDSO mapping, you might want to prelink it to that address
instead of 0; the x86 vDSO is prelinked to a canonical address, but it need
not be mapped at that address.  glibc already copes with the vDSO's
addresses needing to be adjusted (and doesn't try to write into the image).

> vDSO will _not_ and never use/require a TOC by design. The compiler of
> course doesn't know it, but if the symbol is to be called by glibc
> itself, an appropriate asm glue can be used that avoids these. If the
> vDSO symbol is to be directly "linked" to the application by ld.so, then
> OPD's have to be constructed on the fly by ld.so, the value of the TOC
> in them is irrelevant.

However, some value will be loaded from the TOC slot into a register by the
caller, no?  So you might as well consider using this if it's any use;
i.e. a handy pointer to the particular mapping address of the vDSO, which
you can use to find the data you export in the vDSO mapping.

> Note that Paulus and I have been wondering wether it would be worth
> defining a new relocation type for the vDSO symbols to avoid special
> casing in ld.so. That relocation type would be for use by the vDSO,
> defined as "offset to function with no TOC", and might make things
> easier for ld.so to deal with those ... 

It's really not very hard to do the right thing given whatever way of
selecting the special flavor of targets.  It could test the reloc flavor,
bits in the defining symbol table entry, bits in the defining module's ELF
flags, whatever.  So, might as well do the simplest thing first and just
try it out testing a special-case flag in the dynamic linker data
structures that we set only for the vDSO.  Once it works happily we can
worry about the cleanest way to indicate the special treatment.  The choice
among those doesn't make a very big difference at all, but for the dynamic
linker code as it is, using a different reloc flavor would be the most
perturbing, not the least.


Thanks,
Roland