From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8498 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Next steps in fdpic support Date: Sat, 12 Sep 2015 16:41:24 -0400 Message-ID: <20150912204124.GA10172@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1442090550 12921 80.91.229.3 (12 Sep 2015 20:42:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Sep 2015 20:42:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8510-gllmg-musl=m.gmane.org@lists.openwall.com Sat Sep 12 22:42:27 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Zarcw-0005JN-RQ for gllmg-musl@m.gmane.org; Sat, 12 Sep 2015 22:42:26 +0200 Original-Received: (qmail 31947 invoked by uid 550); 12 Sep 2015 20:42:23 -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 30703 invoked from network); 12 Sep 2015 20:41:37 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8498 Archived-At: As of commit d4c82d05b8d0ee97f6356d60986799a95ed5bd74, the fdpic on sh should be generally working for static linking. There are a few places where function calls from asm take place that I still need to review, and at least cancellation probably has a remaining bug, but this is all simple stuff. If anything else seems broken, bug reports are welcome! The next big step is dynamic linking. I jokingly suggested on irc that we could treat each LOAD segment of fdpic libraries as a separate library, since that fits with the current model where every DSO has a single "base" address it's loaded relative to. However I don't think that really makes sense; it would just offload the complexity onto managing the list of libraries where it's uglier, and still wouldn't get rid of all the complexity in symbol lookup. As an alternative, I started auditing dynlink.c for places where the base address of a DSO is actually used. They're almost all of the form: given a DSO and an address within that DSO's virtual address space, translate it to an address where it's loaded in the process's (virtual on mmu, or physical on nommu; no need to care which) address space. So I think the problem of no longer having a single base address is easily solved by abstracting this operation as a function. On non-fdpic targets it would just be a function that adds its two arguments, and which is thus trivially inlinable. For fdpic there's likely to be some runtime cost involved, but that's inevitable. Before starting on the dynamic linker itself, though, the first step is the entry point. Having the static PIE (rcrt1.o) entry point in musl using the same framework as the dynamic linker bootstrap makes it easy to do this as a first step independent of actually having working dynamic linker code. Unfortunately this will require some changes that impact all archs (in crt_arch.h) but that was going to be the case anyway because of the problems (for static-PIE) with depending on exported symbols. Fixing this should clear the way for pushing ready-to-use static-PIE patches into GCC upstream. Rich