From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22969 invoked by alias); 17 Feb 2011 23:07:50 -0000 Received: (qmail 22816 invoked by uid 22791); 17 Feb 2011 23:07:48 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Feb 2011 23:07:46 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p1HN7TSn015248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Feb 2011 18:07:29 -0500 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p1HN7SZ2021685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2011 18:07:29 -0500 Received: from tyan-ft48-01.lab.bos.redhat.com (localhost.localdomain [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id p1HN7Sqn032375; Fri, 18 Feb 2011 00:07:28 +0100 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id p1HN7Ra1032373; Fri, 18 Feb 2011 00:07:27 +0100 Date: Thu, 17 Feb 2011 23:07:00 -0000 From: Jakub Jelinek To: Jan Hubicka Cc: "H.J. Lu" , Jan Beulich , "H. Peter Anvin" , GCC Development , x32-abi@googlegroups.com, Binutils , GNU C Library Subject: Re: x32 psABI draft version 0.2 Message-ID: <20110217230727.GK30899@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek References: <4D5C2DD2.10608@zytor.com> <4D5CEBDE02000078000325A2@vpn.id2.novell.com> <20110217142916.GI13037@sunsite.ms.mff.cuni.cz> <20110217152233.GB11346@atrey.karlin.mff.cuni.cz> <20110217154452.GA18799@kam.mff.cuni.cz> <20110217180646.GB30899@tyan-ft48-01.lab.bos.redhat.com> <20110217224956.GA20055@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110217224956.GA20055@kam.mff.cuni.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00236.txt.bz2 On Thu, Feb 17, 2011 at 11:49:56PM +0100, Jan Hubicka wrote: > The blog claims > Architecture libxul.so size relocations size % > x86 21,869,684 1,884,864 8.61% > x86-64 29,629,040 5,751,984 19.41% > > The REL encoding also grows twice for 64bit target? > > > REL. There might be better ways how to get the numbers down. > > These are difficult since they mostly come from vtables and we need to be > pretty smart to optimize vtable out completely. Mozilla recently started to > use elfhack (in official builds) that is sort of their own dynamic linker > handling PC relative relcoations only. Pretty ugly IMO but they claim 16% > savings on x86-64, 6% on x86 By better ways I meant create new relocations for relative relocs that would be even more compact (assuming we can't or don't want to change the fact that vtables contain pointers instead of pc relative pointers and assuming Mozilla doesn't want to change implementation language to something saner than C++ ;) ). On my libxul.so I see: 0x000000006ffffff9 (RELACOUNT) 161261 Relocation section '.rela.dyn' at offset 0x75a10 contains 186467 entries: Relocation section '.rela.plt' at offset 0x4ba358 contains 4722 entries: so all that it actually matters there are relative relocations. So one way to cut down the size of .rela.dyn section would be a relocation like R_X86_64_RELATIVE_BLOCK where applying such a relocation with r_offset O and r_addend N would be: uint64_t *ptr = O; for (i = 0; i < N; i++) ptr[i] += bias; Then e.g. 0000003ec6d86008 0000000000000008 R_X86_64_RELATIVE 0000003ec5aef3f3 0000003ec6d86010 0000000000000008 R_X86_64_RELATIVE 0000003ec5af92f6 0000003ec6d86018 0000000000000008 R_X86_64_RELATIVE 0000003ec5b06d17 0000003ec6d86020 0000000000000008 R_X86_64_RELATIVE 0000003ec5b1dc5f 0000003ec6d86028 0000000000000008 R_X86_64_RELATIVE 0000003ec5b1edaf 0000003ec6d86030 0000000000000008 R_X86_64_RELATIVE 0000003ec5b27358 0000003ec6d86038 0000000000000008 R_X86_64_RELATIVE 0000003ec5b30f9f 0000003ec6d86040 0000000000000008 R_X86_64_RELATIVE 0000003ec5b3317d 0000003ec6d86048 0000000000000008 R_X86_64_RELATIVE 0000003ec5b34479 could be represented as: 0000003ec6d86008 00000000000000MN R_X86_64_RELATIVE_BLOCK 0000000000000009 I see many hundreds of consecutive R_X86_64_RELATIVE relocs in libxul.so, though of course it would need much better analysis over larger body of code. In most programs if the library is prelinked all relative relocs are skipped and .rela.dyn for them doesn't need to be even paged in, but Mozilla is quite special in that it one of the most common security relevant packages and thus wants randomization, but is linked against huge libraries, so the question is if Mozilla is the right candidate to drive our decisions on. Another alternative to compress relative relocations would be an indirect relative relocation, which would give you in r_offset address of a block of addresses and r_addend the size of that block, and the block would just contain offsets on which words need to be += bias. Then, instead of changing RELA to REL to save 8 bytes from 24 you'd save 16 bytes from those 24 (well, for x32 half of that). Jakub