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/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


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