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~ _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
