This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]