Re: ppc64 vDSO in mainline

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

On Wed, 2005-03-23 at 17:25 -0800, Roland McGrath wrote:
> > 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.

Agreed. That _might_ be debatable for really gory stuffs like the IBM
JVM but let's not argue about this now :)

For some stuffs like the dcache/icache flush routine, though, that means
I would like to have glibc export it (despite not beeing a standard
posix function), maybe under the name make_data_executable() (who says I
have a MacOS background ? :) so that things like Mozilla/Oo module
loader, JVMs, ... can, use it. But that can be debated later too.

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

Yes.

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

Well, since the vDSO may be mapped anywhere and differently for every
process, it wouldn't be convenient to have a differnt p_vaddr for each
instance, so I just link it at 0.

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

Hrm... I used to do that, that is, have the vDSO "linked" at 0x100000
which happen to be unused in pretty much all address space layouts, and
is also where the current kernel maps it... I changed that but it might
not have been the best idea indeed... I can change it back to 0x100000
since 2.6.12 has not been released yet.

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

Good.

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

Unless the caller uses a special asm trampoline (which it has to do on
ppc64 anyway due to the lack of descriptor) which avoids that step. I
was thinking about using that TOC thing in fact to point to the "data"
area of the vDSO (a page of data also shared with the kernel with things
like the calibration infos for the gettimeofday, the syscall map,
etc...), currently, the kernel "patches" the vDSO at boot with the
proper offset to it, but that would mean providing function descriptors
with the proper address which isn't simple, and is not a viable option
for ppc32. I finally decided to not use the TOC at all.

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

Ok.

Ben.