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


Roland McGrath <roland@redhat.com> wrote on 03/23/2005 07:14:40 PM:

> I'd really like to see you do the prototyping step before getting into 
the
> fancy business.  This is was I asked for before.  Take gettimeofday, the
> favorite first example.  Do this by writing a powerpc/gettimeofday.c 
that
> does a lookup using _dl_vsym and caches the result in a static variable.
> Use whatever magic you need to handle the missing descriptor.
> 
> Steve alluded to problems doing a symbol lookup but didn't give any 
details.
> Like I said before, make that work, and ask here for help in how to do 
it,
> before moving on to hairy ld.so hacks.  One thing at a time.
> 

I will work on the hackery for powerpc/gettimeofday, but I wanted to 
start/restart the design discussion about generalized vdso binding and a 
cross platform issues.

For the design discussion I am coming from the view that PLT binding is 
already a well understood cross platform mechanism. Any arch specific 
issues in the dynamic loader are handled by arch specific dl-machine 
implementions of elf_machine_fixup_plt. 

It seems to me that all the additional complications for VDSO binding are 
all on the VDSO side. At least on the archs I am familiar with the PLT 
binding only updates the callers environment. The only requirement is that 
.dynsym table entries are merged into the link map (and they are via 
AT_SYSINFO_EHDR). 

For 64-bit there is an additional requirement to access .opd entries in 
the vdso image. Normally those .opd entries would have to be fully 
resolved before they are copied to the PLT entry by elf_machine_fixup_plt 
(but not necessarily by the dynamic linker). However powerpc64 has a 
mechanism to handle unresolved .opd entries (by adding in the target maps 
l_addr) if target's map is not yet relocated (l_relocated is false). This 
mechanism is required to handle circular library dependencies but will 
also serve to handle .opd entries from a vdso.

The hard requirement being that the loader should/can not relocate the 
vdso itself. Here we are only concerned with .rela.dyn entries in the 
vdso. But we can constrain the code in the vdso to limit/eliminate these 
relocations. Any remaining (local) relocations are simple and can be 
performed by the kernel in vsdo.c. This implies that the kernel would also 
remove the .rela.dyn section from the final vdso image (if it had one).

Another way to elliminate .rela.dyn relocations is to build the vdso for a 
absolute address. I see no value in randomizing the load address of the 
vdso. The functions we are dicussing (so far) are syscall replacements and 
offer no more exposure than existing syscalls. If the vdso is linked for a 
specific address the linker performs all local relocations (no .rela.dyn 
entries).

But if we really need to randomize the vdso load address the kernel can 
relocate a fixed number of the vdso images and ramdomly pick one for each 
process.

There remains to issue of what does libc link to generate the PLT enties. 
The simpliest solution it is link to the vdso??.so for each plaform. But 
there may be more elegant solutions. VDSO also becomes part of the ABI for 
each platform and has to be managed and versioned.

You thoughts please.


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]