From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101817 invoked by alias); 19 Dec 2017 19:41:02 -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 101778 invoked by uid 89); 19 Dec 2017 19:41:01 -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,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=mile, H*Ad:U*gnu-gabi X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-yb0-f175.google.com Received: from mail-yb0-f175.google.com (HELO mail-yb0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Dec 2017 19:40:59 +0000 Received: by mail-yb0-f175.google.com with SMTP id g198so7949942yba.7 for ; Tue, 19 Dec 2017 11:40:59 -0800 (PST) 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=jDg00TUBIPSKzPpAaDG6uJeDO6FQ/VlkMJ5KbToCx4g=; b=VrXUA6rk3y0aBQo2M3i7zkEjmAI+nD83TnOt1cvJamiiI9snIEUjb/0xyeYUnH24YC 8iFlST+ig3q+qtW2MKBmVmhY2hWuZbOiggnmlkytK1hKoKkWVB6892ZYhMKD9fxkAWsS WrrHO2ZVuL/LlfqBPccawhG/aaJ3H4ke/5b3B2c3exT8PYBLLpdWIiNjh6jlRy/Z8EKx uWixCdh6o1K6BbG3gphOd5t28X8QVdW4GsK3zrwcj/qkoXQf7FZsX4KkdaE1mFRk237D 7mLE/jT2HNgtUdHBLXIdDQVdKNVSi0qBpu0d4vjvVlC/1tAvki5fx1TCjFyXsshuq8ym l8AA== 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=jDg00TUBIPSKzPpAaDG6uJeDO6FQ/VlkMJ5KbToCx4g=; b=eQEIQvwD8I6vnv0O7kqnQMmi+dkLt23Lhk+QkTi/ctcqa8yW0Sv6MbtR5xCt7uT0Lp 2pozWzT621O7GXZ+X0wfSORxS/XcPqRHzQUAaQCKhn3lmrJWtp5N5TUKPe2JCY80QS5e 9c2M9XMJqrCr9xyi+LWP4mP7d4DY6hiQ4BvVIknbfy6MgTuwqJ9/hX278md5rs5VGR1C Y2bPcs8/5Bjx9JTUHLB0hmmv06t7dRnZAoAXCpPkrnkMyURhfqfGFqg9mpIeIn8LPtWM x816ZPvaIzkteWCHUa8kBCMAoyScPrQsA7kvKuGrI4z29ojNqy4c9V0eAomOCJEqNU/l EtzA== X-Gm-Message-State: AKGB3mLISjdcBhR1eUqDTr2PxZur5Gvr44jZ4R24OfzZS4gSMTuOjaiw KuKkcwXpoH+fMhunsFbjyZ1jf+PcCHz1eCFK4712hA== X-Google-Smtp-Source: ACJfBoso7nretgc3zjB2nrSw4+CQ/1334oagMDxEvwejS12crH3mOnmjWVE7Pu5qmo74+vXARSvAFEifeCkAKZzaV1Q= X-Received: by 10.37.248.36 with SMTP id u36mr3384231ybd.506.1513712457690; Tue, 19 Dec 2017 11:40:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.104.69 with HTTP; Tue, 19 Dec 2017 11:40:56 -0800 (PST) In-Reply-To: References: <8737cosnym.fsf@localhost.localdomain.i-did-not-set--mail-host-address--so-tickle-me> <7e698a5f-32d7-6549-7e23-8850b85e6c10@gmail.com> From: "Rahul Chaudhry via gnu-gabi" Reply-To: Rahul Chaudhry 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: Sriraman Tallam , Suprateeka R Hegde , Florian Weimer , David Edelsohn , Rafael Avila de Espindola , Binutils Development , Alan Modra , Rahul Chaudhry via gnu-gabi , Xinliang David Li , Sterling Augustine , Paul Pluzhnikov , Ian Lance Taylor , "H.J. Lu" , Luis Lozano , Peter Collingbourne , Rui Ueyama , llvm-dev@lists.llvm.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-q4/txt/msg00026.txt.bz2 We sent a proposal to generic-abi last week. Here's the link for cross-reference, as promised: https://groups.google.com/forum/#!topic/generic-abi/bX460iggiKg Rahul On Mon, Dec 11, 2017 at 4:05 PM, Rahul Chaudhry wrote: > Thanks for your encouraging words, Ian and Cary. > > We're drafting a more detailed proposal and would post it on the generic-abi > list this week. I'll also post a link here for cross-reference. > > Based on Cary's suggestion here, we're renaming '.relrz.dyn' to > '.relr.dyn' in the > proposal. > > Rahul > > > On Fri, Dec 8, 2017 at 10:36 PM, Cary Coutant wrote: >>> We've taken the '.relr.dyn' section from Cary's prototype, and implemented a >>> custom encoding to compactly represent the list of offsets. We're calling the >>> new compressed section '.relrz.dyn' (for relocations-relative-compressed). >> >> I'd suggest just using .relr.dyn -- your encoding is straightforward >> enough that I'd just make that the standard representation for this >> section type. >> >>> The encoding used is a simple combination of delta-encoding and a bitmap of >>> offsets. The section consists of 64-bit entries: higher 8-bits contain delta >>> since last offset, and lower 56-bits contain a bitmap for which words to apply >>> the relocation to. This is best described by showing the code for decoding the >>> section: >>> >>> ... >>> >>> The above code is the entirety of the implementation for decoding and >>> processing '.relrz.dyn' sections in glibc dynamic loader. >>> >>> This encoding can represent up to 56 relocation offsets in a single 64-bit >>> word. For many of the binaries we tested, this encoding provides >40x >>> compression for storing offsets over the original `.relr.dyn` section. >>> >>> For 32-bit targets, we use 32-bit entries: 8-bits for 'jump' and 24-bits for >>> the bitmap. >> >> Very nice! Simple and effective. >> >>> Here are three real world examples that demonstrate the savings: >> >> Impressive numbers. I've gotta admit, the savings are better than I expected. >> >>> However, before that can happen, we need agreement on the ABI side for the new >>> section type and the encoding. We haven't worked on a change of this magnitude >>> before that touches so many different pieces from the linker, elf tools, and >>> the dynamic loader. Specifically, we need agreement and/or guidance on where >>> and how should the new section type and its encoding be documented. We're >>> proposing adding new defines for SHT_RELRZ, DT_RELRZ, DT_RELRZSZ, DT_RELRZENT, >>> and DT_RELRZCOUNT that all the different parts of the toolchains can agree on. >> >> Yes, as Ian mentioned, the generic ABI discussion is at >> generic-abi@googlegroups.com. Most people who would be interested are >> already on the gnu-gabi@sourceware.org list, but there are a few who >> are not, and who may not yet have seen this discussion. I'll support >> the proposal. >> >> Thanks for taking this idea the extra mile! >> >> -cary