From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58073 invoked by alias); 9 Dec 2017 06:36:27 -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 58049 invoked by uid 89); 9 Dec 2017 06:36:26 -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.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=gotta X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham 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-wr0-f175.google.com Received: from mail-wr0-f175.google.com (HELO mail-wr0-f175.google.com) (209.85.128.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 09 Dec 2017 06:36:25 +0000 Received: by mail-wr0-f175.google.com with SMTP id z34so12632175wrz.10; Fri, 08 Dec 2017 22:36:24 -0800 (PST) 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=PAiWNMlRJEpmKLX3t/g47JmlA6aMcAmRS7NzHc6SbO8=; b=FKxvPZ+E82SkfoQODMqD1BJWO8F79n9jklh3cgp01t7pIkPGU63IsOSO6kAKZw5sd6 wgcy1whRe523oVZ2Y1cuZ3eSZjgyWcDUHRdlK1ooIm8SSt6oSYS49p3tcSLn42yQ2Aap fAOahcqIAKh9bTG2SrqPsCSaG9pDKuhjLFuJENMDzyQNMZzadRnVZZaS7+NGLaJlb+s+ 9tOYeTKAAswQtTyHxiHRBydJnJ6bmPMM6YlIvpZJGeAYVLVnFxHW2g7eTMlww2a6/Pnt rL9OgpWk3y0u4HAR84AltMrsHFkn2mnDjHwQYKFUslk/VOVOgsHrOI5DgKidPYabzksW CjXw== 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=PAiWNMlRJEpmKLX3t/g47JmlA6aMcAmRS7NzHc6SbO8=; b=UxMDKBG/wLWh/RpdgkYiY5vGUyVPiB8JmPM1ryXoaZF8O2S84kxIvrFfid76wHIcRN XbVDktClaX09ik6Oc5S1xFdS+l80VLYYu8m6OqHX+QCXvDG9T+8D9/gL/26/ySB9HEn9 sAmFjBdv5gZ/KspfoQEBELpEki45/bFhRfGhTThRvLMx9XmlJPnT5a2Fgvuhwd5wbe7g Zvgp1jhrhnWEzKDMUtnEnMXcQdIrA8bZI5AG75qhdWBIj7MU0MuYGGG5xhvM8xKo5HvG QihwYPj6gIH96QMkFbXn12t4jNKfJvuB2x2gBoA80yZjes7zsqVZ2SUk1/OBRiPOZy8o dcEw== X-Gm-Message-State: AJaThX5kRDGoS0yOdK1v8zYXiTbd9KsWb6Wky1ZkNXeOXrtx1SF/kOYL 7Oli8kSD23ty0/OajgOfKk4whu60kIpVqZevzGU= X-Google-Smtp-Source: AGs4zMZhkgc8JkeM14kWL+kjhZyrtrdZjwwwgKheSGyNilyU0eR1Ll7XXxXpAa40/EerbNdRCa29LqE8whpAqLkgw9Y= X-Received: by 10.223.168.35 with SMTP id l32mr29976757wrc.261.1512801382920; Fri, 08 Dec 2017 22:36:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.150.35 with HTTP; Fri, 8 Dec 2017 22:36:22 -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: 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: Rahul Chaudhry Cc: Sriraman Tallam , Suprateeka R Hegde , Florian Weimer , David Edelsohn , Rafael Avila de Espindola , Binutils Development , Alan Modra , gnu-gabi@sourceware.org, 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/msg00007.txt.bz2 > 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