From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119718 invoked by alias); 28 Apr 2017 06:25:11 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 118864 invoked by uid 89); 28 Apr 2017 06:25:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1284 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Apr 2017 06:25:09 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D6801C057FA8; Fri, 28 Apr 2017 06:25:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D6801C057FA8 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com D6801C057FA8 Received: from oldenburg.str.redhat.com (ovpn-116-151.ams2.redhat.com [10.36.116.151]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6EFA193DBE; Fri, 28 Apr 2017 06:25:05 +0000 (UTC) Subject: Re: Reducing code size of Position Independent Executables (PIE) by shrinking the size of dynamic relocations section To: Cary Coutant , 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 References: From: Florian Weimer Message-ID: <4f55a033-0e81-e83c-31d0-9e54813528ab@redhat.com> Date: Fri, 28 Apr 2017 06:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00272.txt.bz2 On 04/26/2017 06:06 AM, Cary Coutant wrote: > 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. It might also be possible to sort the relocated objects so that they are more contiguous. It could be beneficial to arrange things so that vector instructions can be used for the relocation. I'm not sure if it is worthwhile to design a compression scheme based on bit fiddling for this because those who want compression can probably use a compressed file system anyway. Thanks, Florian