This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: ppc64 vDSO in mainline
- From: Steve Munroe <sjmunroe at us dot ibm dot com>
- To: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- Cc: Alan Modra <amodra at bigpond dot net dot au>, libc-alpha at sources dot redhat dot com, Roland McGrath <roland at redhat dot com>
- Date: Thu, 24 Mar 2005 17:31:01 -0600
- Subject: Re: ppc64 vDSO in mainline
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 03/24/2005
03:17:17 PM:
>
> > 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.
>
It will if we agree to change it. I am exploring options that will work
across multiple platforms as Roland has suggested. So just relax while we
figure this out.
>
> > 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.
>
This is an interesting negotiating position but irrelevant. Think of the
current powerpc vdso rendition as the prototype. The history of Linux has
many examples of this :)
> > 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.
>
The dynamic linker does not pass the TOC to anybody. All TOC relocations
are relative to the start of the module. The caller picks up the target
TOC pointer from the .opd entry of the target function from the target
module (or the PLT entry which is copy of the .opd entry).
So the kernel's vdso.c can relocate the .toc entries for the vdso64.so if
needed.
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center