This is the mail archive of the
mailing list for the glibc project.
Re: ppc64 vDSO in mainline
- From: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- To: Steve Munroe <sjmunroe at us dot ibm dot com>
- Cc: Ulrich Drepper <drepper at redhat dot com>, Alan Modra <amodra at bigpond dot net dot au>, libc-alpha at sources dot redhat dot com, Roland McGrath <roland at redhat dot com>
- Date: Sat, 26 Mar 2005 10:13:58 +1100
- Subject: Re: ppc64 vDSO in mainline
- References: <OF1302663D.6FEF6812-ON86256FCF.0075FCB4-86256FCF.email@example.com>
> I am trying to understand the design requirements which are not the same
> as the current implementation.
> I am pressing this issue because the current definition is unnecessary
> restrictive. Even with the restrictions you have given (including
> randomization of VDSO base), I am convinced that powerpc32/powerpc64 can
> use normal PLT binding for VDSO functions. I also believe this can be
> extended to the other platforms. This will be a benefit to all.
> It turns out that powerpc32 works as is and powerpc64 should work with
> unrelocated (but ReadOnly) .opd's (they will be relocated by
> ld64.so/elf_machine_fixup_plt when copied to the PLT). Using the .got or
> .toc with the VDSO is slightly more complicated and we can cross that
> bridge when we come to it.
If you want to experiment with that, I think I left the option to build
the descriptors in the vDSO code (though I haven't tested it for a
while, it might not even build ...). In include/asm-ppc64/vdso.h, turn
> For gettimeofday a kludgy interface does not matter (much) but as we look
> at other opportunities for processor specific optimizations the overhead
> of this interface does matter. A function pointer is slower (~6 cycles)
> than a direct branch and the powerpc32 PLT fixup will update the PLT with
> a branch absolute (1 cycle), if the targer is anywhere in the lower 32MB
> of the address space. On POWER4/5 I can move or compare a lot of bytes in
> 5 cycles.
But ppc64 will always load pointers from OPDs no ? That is, ppc64 will
always end up using function pointers no ? ppc32 is not a problem, as
you stated, it works as-is and doesn't need descriptors anyway.
> Ok, but as I understand the design requires and trade-offs I will continue
> to explore alteratives.