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: Roland McGrath <roland at redhat dot com>
- Cc: Alan Modra <amodra at bigpond dot net dot au>, Benjamin Herrenschmidt <benh at kernel dot crashing dot org>, libc-alpha at sources dot redhat dot com
- Date: Thu, 24 Mar 2005 16:50:40 -0600
- Subject: 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