Date: Sat, 21 Jan 2012 23:30:47 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Dynamic linker refactoring On Sat, Jan 21, 2012 at 01:19:40PM +0100, aep wrote: > On Fri, 20 Jan 2012 20:05:54 -0500, Rich Felker wrote: > >Hi all, > > > > I'm leaning towards stripping out the vdso > >(linux-gate) support at the dynamic linker level entirely, and > >instead > >using Nik's original design for vdso-assisted clock_gettime which can > >work with static linking too. > > isn't the vdso there for much more then just clock_gettime? Ie for a > whole bunch of syscalls that otherwise need to go through the slow > interrupt path? I wouldn't say a whole bunch. At present there are only one or two other functions provided by vdso and their applicability is so limited I can't see them benefitting anything. Certainly there is a fair bit more that could be implemented by the kernel in userspace in the future, though. What I originally thought was useful, but now I'm rethinking, is the practice of actually including the vdso as a dso in the main chain of loaded dsos, where its symbols become globally visible (including accessible by the application using dlsym, for example). In principle, it could replace symbols from the libc with its own versions. The fact that I ordered it after libc rather than before partly ameliorates this problem, but if the symbol in libc is weak, it can still be overridden by a strong symbol in the vdso. (In fact this is how __vdso_clock_gettime currently works!) If used correctly, it's no big deal, but it would be quite unfortunate if the kernel developers went and added some override that was intended to work with glibc but broke horribly with musl.. Anyway with that in mind, I'd thought about at least 2 possible alternatives: 1. Load the vdso through the dynamic linker code, but don't insert it in the dso list, and instead search out the symbols we want from it directly. 2. Include the vdso-linking code directly in the functions (like clock_gettime) that might want vdso code. Option 2 has the advantage of working even with static linking, but in the immediate it would cause more code duplication. In the long term, on the other hand, it might lead to better code factoring by allowing us to move some of the hash, symbol table search, etc. code out of dynlink.c and into a module that could be reused both for the vdso search in static binaries and by the dynamic linker. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.