From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/545 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Dynamic linker refactoring Date: Sat, 21 Jan 2012 23:30:47 -0500 Message-ID: <20120122043047.GN132@brightrain.aerifal.cx> References: <20120121010554.GA8306@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1327207913 5307 80.91.229.12 (22 Jan 2012 04:51:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 22 Jan 2012 04:51:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-546-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jan 22 05:51:49 2012 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1RopPA-0006Qs-WE for gllmg-musl@lo.gmane.org; Sun, 22 Jan 2012 05:51:49 +0100 Original-Received: (qmail 3537 invoked by uid 550); 22 Jan 2012 04:51:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3529 invoked from network); 22 Jan 2012 04:51:47 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:545 Archived-At: 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