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: Wed, 23 Mar 2005 17:13:18 -0600
- Subject: Re: ppc64 vDSO in mainline
Roland McGrath <roland@redhat.com> wrote on 03/13/2005 03:24:45 AM:
> > On Sun, 2005-03-13 at 00:56 -0800, Roland McGrath wrote:
>
> We the maintainers of the dynamic linker would have to put some effort
into
> coming up with the right ways to do this. But we'd need to have a good
> motivation for such effort, which as yet does not exist outside ppc64.
>
I am starting to look at conecting glibc to to the VDSO
__kernel_gettimeofday(). We have a few things to work out.
So far my attempts to use (almost) normal require that the application be
linked to vdso*.so to use extern or even dlsym resolution.
extern int __attribute__ ((weak)) __kernel_gettimeofday(struct timeval
*, void *);
It seem that ld will not put the reference into the .dynsym table unless
it has found the symbol in a dso at link time. Link to the vdso*.so also
allow the extern/dlsym to resolve.
The result of this is the vdso showes up in the NEEDED list:
Dynamic segment at offset 0x1520 contains 23 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library:
[linux-vdso64.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
but this does not seemt to cause any trouble because the vdso is already
loaded. This link time bind also puts generates a UND ref in .dynsym
table.
Symbol table '.dynsym' contains 19 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 24 FUNC GLOBAL DEFAULT UND dlsym@GLIBC_2.3
(2)
2: 0000000000000000 24 FUNC GLOBAL DEFAULT UND fgetc@GLIBC_2.3
(3)
3: 0000000000000000 92 NOTYPE WEAK DEFAULT UND
__kernel_gettimeofday@LINUX_2.6.11 (4)
4: 0000000000000000 24 FUNC GLOBAL DEFAULT UND
gettimeofday@GLIBC_2.3 (3)
So this becomes the first decision point. For binding libc functions
internally to vdso function we could do ld.so magic to get the entry
points directly out of the ELF HDR or out of the link_map (BTW I would
appreciate some pointers in that direction as Alan Modra is on vacation
... not which function to call & parms to use.) But that is not a general
solution and is unsatisfactory for performance sensitive functions like
memcpy/memcmp (because it implies another level of indirection)
A more natural mechanism first requires a mechainsm to expose vdso symbols
(does ld have to see vdso??.so or some special linker script) and how to
fit this into the glibc configure/make system. Do we want glibc linking to
the kernels vdso? Or should we build a dummy vdso within glibc just to
support linking? This is important for internal libc binding (to vdso) as
well any general usage.
The first thing we would like is vdso call via PLT. This requires that the
VDSO exports enough info to resolve the PLT ref. This seems simple for
ppc32 as the target function address is needed from the link map. For
PPC64 (and other 64-bit platforms) the VDSO will have the export
preresolved .opd entries (The .opd entry is simply copied to the PLT
entry).
Ben:
I did manage to call __kernel_gettimeofday(), but
There is also a problem with the current ppc vdso64.so where it exports
the actual function address instead of the expected function descriptor
address (.opd entry). This requires the caller to manufacture a function
descriptor at runtime and disallows any thoughts of normal (PLT) call
binding. It would be helpful if the vdso64.so followed the ABI but the
kernel will have to insure that the .opd entries are pre-resolved.
There is also the question of the TOC. The currently all functions are
leaf routines so a TOC is not technically required. But normal binding
will will (try to) load a new TOC for the VDSO anyway.
Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center