From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75080 invoked by alias); 26 Apr 2017 17:34:18 -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 75040 invoked by uid 89); 26 Apr 2017 17:34:16 -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=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=nuisance, chrome, ccoutantgmailcom, ccoutant@gmail.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,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-HELO: mail-io0-f176.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v3WZWzH9M7rnRWMuX+T+i7Nus2v0a+SxT9fKKX5UtN8=; b=sjL7Brb2YvnOZF3TONcjvhJ8qfCIRXs1scjwxrYMpSkLmQTPWs5BuTdcTtt6dXq3Fw f77Uw8GsVYJaTGFH+FZC459g8X766o1AHsDHV+q2pM/y8/Na54gN7afmcTp9+1sHK7ya i4Tpmvu5qiIWcKHwJP+KjDMTIbgwitSyIn/nrckaecbKlzDNaI6YZ0N9WHEf3ZuSM3rs B3uyr9zTYLlx+Bwer55RCo17aFyRw0RL/h6wr+ykf4rpRrSXLEo2mUcUKXBZIF5dVLM7 VALSPCgCg9p5t75A+739fjN/ZXAi3W73USE10rpb5rt4FnZmixgJGaBgpDqjQR1vV4QS VG2Q== 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=v3WZWzH9M7rnRWMuX+T+i7Nus2v0a+SxT9fKKX5UtN8=; b=X4mTeDxFMbqMIDgLQqr1JAhJNLKb3CS+2ZiNR2+ZNeJFYBT5/0hreNvdH7Z6WeB7QH ZxdgD4tRMOn73essMOvyEbs8ifRy9O9VL+j2v0m6AQuTYg9fjfCiQ9Qqfif1RzoUAp7U hPW8k1iMMD9+eZbU4zMYGOzxmYnw0apeTTA4npt3jJqDqKkTNP6YT9HG2/G9nDLDSqmf JdOA60nTy6PdifcdDbA7Q9+VThF0pJKlBTwncBW6NhifnMUvXgh4rdk9SgXcEJfM+KjH ucF0tsbDza/mfebmPxhbrnDfyFOZ5vtioh11HbuhpXxPj1r6FJpoTMJ0TOg0A9S7uIqv wy0A== X-Gm-Message-State: AN3rC/5CJL3F/qIKN82ZuywSDwWFEdvTUEoX/iWXDzZseUfLHzyR2aLz IAlQlTSArwDPGlCxOy1BLpISTRG4Qc3YznspPQ== X-Received: by 10.107.173.14 with SMTP id w14mr973284ioe.232.1493228055233; Wed, 26 Apr 2017 10:34:15 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Sriraman Tallam 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: Cary Coutant 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/msg00006.txt.bz2 On Tue, Apr 25, 2017 at 9:06 PM, Cary Coutant wrote: >> 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!) Ok, here is how I understand the impact of these savings : * In terms of text size, the size savings on most binaries is equal to what ICF can offer and is on top of ICF. * Some of our binaries are forced to disable PIE because they are stored in space constrained partitions and this will make it possible to enable PIE again for them. * Chrome/ChromeOS binaries enable full ICF (not safe) and are willing to take the debugging nuisance that comes along with it for the savings, so I am assuming this would interest them. > > 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. Thanks!, you have shown me a clear path forward. > > 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*. Ok, I guess Step 4 can be done in a later iteration. Thanks all for the inputs. Sri > > -cary