On 07/08/2011 09:55 AM, Dave Martin wrote:
Talking to Will Deacon about this, it sounds like there may be little appetite for VDSO-ifying the vectors page unless there's a real, concrete benefit.
Making the libc startup's job slightly easier probably doesn't count as such a benefit, but if it renders possible something which is otherwise impossible to do from userspace than that would be more compelling.
I don't consider it anything to do with "making libc's job easier", but of providing a standard mechanism for version control of the ABI.
All you're going to do by using a different mechanism is re-invent the wheel.
There's limited support for dlopen within statically linked programs as well. The userland side can provide a static interface which defers to the kernel implementation.
But you don't dlopen the VDSO, it's just mapped by the kernel on process startup. To find it, on other architectures something in the C library needs to grab the base address passed by the kernel in the aux vector.
Of course. Did you think I didn't know that? And so does the dynamic linker, and the dynamic linker stub in libc.a. The point is to get a handle that you can pass into the other functions like dlsym.
See also _dl_vdso_vsym in libc/sysdeps/unix/sysv/linux/dl-vdso.c, and the uses in libc/sysdeps/unix/sysv/linux/*/init-first.c.
Can individual IFUNCs be set to resolve at startup?
No. They're kinda sorta a special type of PLT entry. So they're resolved either when called, or at startup. See also LD_BIND_NOW for the entire program and DT_BIND_NOW (-Wl,-z,now) for individual libraries and executables.
r~