From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7366 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Dynamic linker changes Date: Wed, 8 Apr 2015 19:19:11 -0400 Message-ID: <20150408231911.GK6817@brightrain.aerifal.cx> References: <20150405223031.GA29575@brightrain.aerifal.cx> <20150405225533.GH6817@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 1428535171 1055 80.91.229.3 (8 Apr 2015 23:19:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Apr 2015 23:19:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7379-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 09 01:19:31 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 1YfzFo-000221-2c for gllmg-musl@m.gmane.org; Thu, 09 Apr 2015 01:19:28 +0200 Original-Received: (qmail 32723 invoked by uid 550); 8 Apr 2015 23:19:26 -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 32704 invoked from network); 8 Apr 2015 23:19:26 -0000 Content-Disposition: inline In-Reply-To: <20150405225533.GH6817@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7366 Archived-At: So far I've been hitting some ugly obstacles: 1. If we want the new code to eliminate the need for platform-specific __reloc_self functions for mips/microblaze/powerpc/etc., the first phase needs to perform relative relocations without making _any_ function calls, since even calls to static functions go through (anonymous) got entries. That's not such a bad idea if it would eliminate this ugly per-arch code, but... 2. The current method of making relocations generic rather than arch-specific uses a function/switch statement to remap them. This is not going to be usable for solving item 1 above in an arch-agnostic manner. So perhaps we should replace this function with a set of macros. Rather than having generic values for the REL_* macros and mapping the R_{arch}_* values to them with switch, we could do something like (example for microblaze): #define REL_SYMBOLIC R_MICROBLAZE_32 #define REL_GOT R_MICROBLAZE_GLOB_DAT ... However it's not clear to me whether the mapping from arch-specific reloc types to generic ones is one-to-one in all archs, so we'd potentially have to have extra macros like REL_SYMBOLIC_2. One benefit of this approach, on the other hand, is that the switch in the portable reloc processing code can have #ifdef around each case and eliminate code for relocations a given arch doesn't support. (Technically the compiler's dead code elimination could already after inlining the mapping function or performing inter-procedural range analysis, but I seriously doubt it did so.) 3. The original plan was to have one early-ldso-relocation step and avoid all possible GOT/globals use and everything after that free to use arbitrary global data and symbols, with a single barrier in between to prevent reordering of GOT loads before they're relocated. This seems impractical since it's hard, due to issue 1, do to symbolic relocations without being able to make function calls. Instead I'd like to treat the early-ldso-relocation process as two steps. The first is generalizing and making arch-agnostic the work mips, microblaze, and powerpc are doing now to get to a state where all non-symbolic global accesses are safe. The second would be a separate function call from the asm (or chained from the first if there's an obvious way to do it) that performs symbolic relocations on itself. It would end by (as proposed in the sketch before) doing a symbol lookup and final call into the code that will setup the dso chain, load dependencies, perform all remaining relocations, and pass control to the program's entry point. Rich