Re: ppc64 vDSO in mainline

[Roland McGrath <roland at redhat dot com>]

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

Sure, I mean applications are free to do whatever ill-advised things they
like and have their own private maintenance nightmares.  But I mean that
from the glibc perspective we will not be expecting to worry about any
such things.

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

The need to do this exists on many machines.  So there may be some reason
to have a clean general interface for it, in some library or other.

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

If you do, I think it will be fine.  But, I'm not sure there is much
benefit one way or the other.

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

That's what I'm suggesting.

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

But if the descriptors are going to be synthesized by the dynamic linker
anyway, then it is indeed quite simple to make them with whatever address
you like.