From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59706 invoked by alias); 26 Apr 2017 04:07:39 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 58066 invoked by uid 89); 26 Apr 2017 04:06:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=devoted, cary, cleaned, Hx-languages-length:3104 X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-wm0-f47.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9wqXUQGMkI+vIpI/Ygek2SdGZjeqJe7UHk/QywLOeE0=; b=twKaRG3YH9tWmqX61hplu9LNhEZRgpa+0ykxXIc/Tb5e4UbkWb5j6GUUyRuFXATw6z 14tF13NPYHofBhCs7EuYDrXYE6W/mHBry+DzYHD+cjXbJpJ2Mvm5xi/vwOwmsM+dRZZi a4o+DJIwhjmkCwBYjsn4nuZFHWvb2PgNq9FeYq0k8LuNpD8dGTzQu+U0XYK5mL47fDAO MO3/wZxxQTx/huB8xH+R0QGtrBQyr0UdNuwtfGUa4xkCF8JmX+rh37M1NHr/EikjGtjW NYYu0zR2d9IXjDUhckejP19gFdacuhTn4eHQbIpugDl3a4/MmOkSVd9tm41It3YFRwLc 5Uzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9wqXUQGMkI+vIpI/Ygek2SdGZjeqJe7UHk/QywLOeE0=; b=kWLR0mp4lKc4NXS1iMomU/3YxpXSVbE2kGehijuY2K6TrbnwL0nK9v7A5pIZobSmud YOuQgkeeEw+b4Vmo/MN9m23RCJkmhYKj4G4YWbc1vp6Yz4RYYblUXXifIUc3bJe0lStS ketMgJENveAYqSacyMdIJIh1rlO2YUYeg4eJaXKDtd3yLrZvQdsPIEYntLbOitLEx8Ge rik6vm+y906RtULEdfq+6rffLXzS19HSmgKK2t6Ll8g1GY5HvmN+V4Zj+jb69IfmcVdL WPUE4/iRxI0AtQvLof1DXMOtiAPqmiw+BRoTQZY7jow+almLgCS1ZHEV76+84BTRclR0 3pgg== X-Gm-Message-State: AN3rC/6eZIk55tY2Aud11bR8sAtvA5xnALRXHsglNb5+jTiwycab3ZWc feqPz+dlR90udYr0U2TWMz14cHXyxQ== X-Received: by 10.80.151.214 with SMTP id f22mr7739642edb.54.1493179589676; Tue, 25 Apr 2017 21:06:29 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Cary Coutant Date: Sun, 01 Jan 2017 00:00:00 -0000 Message-ID: Subject: Re: Reducing code size of Position Independent Executables (PIE) by shrinking the size of dynamic relocations section To: Sriraman Tallam Cc: gnu-gabi@sourceware.org, binutils , Xinliang David Li , Sterling Augustine , Paul Pluzhnikov , Ian Lance Taylor , "H.J. Lu" , Rahul Chaudhry , Luis Lozano , =?UTF-8?Q?Rafael_Esp=C3=ADndola?= , Peter Collingbourne , Rui Ueyama Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-q2/txt/msg00003.txt.bz2 > Idea A: Shrinking the size of the dynamic relocations In a RELATIVE relocation, the r_offset field is really the only field of interest. The symbol and addend are not used -- the dynamic loader simply adjusts the address at the given offset by the relocation factor for the load module. Thus, it truly is possible to reduce these relocations to just the one word. Simon Baldwin did a lot of work on this a few years ago for Chromium, writing a post-link utility to extract all the RELATIVE relocations and rewrite them to a new section. When Simon was working on his utility, I decided it wouldn't be too difficult to implement it directly in gold, and I toyed around with it, but never devoted the time to take all the steps it would take to bring this about. (Frankly, I was underwhelmed by the quoted savings, but it sounds like I may have underestimated the value of that savings. Sorry!) Anyway, I cleaned up what I had done a bit, and pushed it to a personal binutils branch, users/ccoutant/experimental-relr, for your consideration. Here's what I did: 1. Added a new section .relr.dyn, with a new type SHT_RELR, and sh_entsize = address size. The contents of this section are (for now) a simple list of addresses that require relative relocations. 2. Added new dynamic table entries, DT_RELR, DT_RELRSZ, and DT_RELRENT, which point to the new section. 3. Added a linker option, --experimental-use-relr, to enable the feature. 4. Modified the x86-64 target to emit new-style RELR relocations. I punted for 64-bit relocations on x32, and for IFUNC relocations -- those will still be emitted as old-style relative relocations in .rela.dyn. For my experimentation, I picked the next-available values in the gABI-reserved range, rather than vendor-specific values, for no good reason. They're easy to renumber if we need to experiment with this in the wild before standardizing. Still to do: 1. Modify the other targets in gold to support RELR relocations. 2. Add readelf/objdump support. (You can still use readelf as is -- it'll just show the section type and dynamic table entries as numbers. And you can dump the new section with "readelf -x.relr.dyn".) 3. Add dynamic loader support. 4. Evaluate some alternate representations to improve upon the simple list of addresses. An idea I've been considering is emitting a bitmap -- an alternating series of pairs (starting address, bits), where "bits" is just a fixed-size bit vector describing each word starting at the given starting address. The "bits" field could be, say, 128 or 256 bits in length, or could begin with a byte that defines its length. I think this would work well, as the relocations are often clustered, but haven't yet done any testing of that hypothesis. A simple run-length encoding, as previously suggested, would also work, of course. I'm not in favor of using a general-purpose compression algorithm on the relocations. 5. Make a proposal to the gABI to add SHT_RELR and DT_RELR*. -cary