From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69999 invoked by alias); 12 Dec 2017 00:05:37 -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 69947 invoked by uid 89); 12 Dec 2017 00:05:37 -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=unavailable version=3.3.2 spammy=encouraging 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=unavailable 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-f171.google.com Received: from mail-yb0-f171.google.com (HELO mail-yb0-f171.google.com) (209.85.213.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Dec 2017 00:05:34 +0000 Received: by mail-yb0-f171.google.com with SMTP id z11so2248622ybm.1 for ; Mon, 11 Dec 2017 16:05:33 -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=unQMvkWCa17PDAe81GkVzS/tymnzJqJlrM1M0NHe220=; b=tlLqK9sOYz+xmlZao1oerCXjLLj9rxMAyVGTKTveEpBf+Etp2a7Htpc4hY8kZHquX6 /73ZE7NGKRuuBPfmFXQJX4fbT9R5PVnVhfXuGZ9AnhMweeaWCOQvB8Zud4vMM0wmI05p 2qFuYL3RFVcb1qbSgzlcLbkpwkqfcUPv+KpiYqNKVslglIGnKlKIrKAeWSZsSpGnh+nW timbqIhgvVILGOCVE7Hel1SlP4UnhDRcV2UeLNMXp9Aq3+3ZG3s8LYG+zxDFyESHUogj +mgRBsAzWzdiErVWNOySux5hCyU7s1dbX5TI43aXbKpfYgphfsel/cPk0is4yCMa4lL8 vLzg== 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=unQMvkWCa17PDAe81GkVzS/tymnzJqJlrM1M0NHe220=; b=CPTQ107sU+nJ5XwpKgavBbfpHTmLb8AlH46jEUmf0+bCvFoWWNncKDEtqoYw3BTPQ3 NrQeD/4K61AtV1nJOnvIe84QWJyTwpsj6ig4ROZfdkdpSOpRctS2ipwPYZwBDk26/nru +/UPu5v6SH8Zf2tWgFJN3ZFk6IM9zv2w1SlhJmY7OJrXTfHoo7NhzyFL4P7L99S/OdmR 9GCNERjkK1+tnW6CT/FTGl44LglvKHa6mJJDKGSf4XfkhcBhcP9AhKCRCiP7zsOjJcws 1bHFmdmxAwxnUdqT80R/QYUM2cs2lP2kZ8f6xNBNDR7DZ2WIEJcsDOk0UV0qFNB2a1Sy gH9w== X-Gm-Message-State: AKGB3mIf0hq+IffaOOslbYG/aG6fTcXZNFl5qm8e2YUyO3HHswICPVYn FsEzc2N/3VBN5qLIijlwQTYbkGbPKyym3s/3OOJOTg== X-Google-Smtp-Source: ACJfBosQAJGsDxCvEeyPsGsTRLacM009OyZVgM+2Np45rIIz7ofzLvZ5ayigkdQOq4XiaqQXwdTfZLMPWVtB3GvDZmk= X-Received: by 10.37.132.71 with SMTP id r7mr1637103ybm.506.1513037132123; Mon, 11 Dec 2017 16:05:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.59.11 with HTTP; Mon, 11 Dec 2017 16:05:31 -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/msg00016.txt.bz2 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