From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95095 invoked by alias); 28 Apr 2017 08:36:17 -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 95057 invoked by uid 89); 28 Apr 2017 08:36: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=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*MI:sk:4f55a03, favour, H*i:sk:4f55a03, H*f:sk:4f55a03 X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,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-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-pg0-f67.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=T4o5AhOVgy0JjWFs3FjDrtqL/aWTTSso3lzLP17kpAs=; b=gUZtM/SZiD8OUJiXb0f+dCONV91eOMDuELRCNNLuD0MKdqogiacc4UpOV9UTeoM6xy sP4gNeWc17QyBRYgVcg7t0OaHZwfZLDHEytU0xhdchPJMXSkpIvn5W9be1BcauA/7p2U Yjt7yUziOVF7+L+wvjZE9Uuxjbmapt2N5CPFB3HOOGpYil8FQ9YLToQDA7+MOmuLOrqp MO24/hHUfvrI8xSyrN+99sfRl/jFDr4lD3qqipf+SicZtxhHgXX/nfylalSjqZvhhhhP 6kmi4w02DNRiQX7RJN07w8ydX5LgEAP4O7sKad5rjMoGqOCVMLwgY/yTk2LkqeqotSK1 Vu1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=T4o5AhOVgy0JjWFs3FjDrtqL/aWTTSso3lzLP17kpAs=; b=umcn2vMdATjXnMyuTjm5goNnbcS1JaNsXzJcAkOdjP2G+MHz+WMxD3FYtdIK3hzey9 MJKu/0jIxKtZnjLc7b73o8+Hqgnb+Mgk2/6Jo5kVYpNes2LQhchGsqbWd3guRZvKskNa K4/XZF1BY9Jn4+KCyyVJPRHuTWqpxf9wwe67VEWZ2K6yI/StePWXGHCTgu+WNTGJx+nS /id0inRFHXhN3wj9ze0hkPL3UUWoDutZCbGrx5mjXGNrG5vcDp/5gp/Wd9+wMYl3h6pr gdrNYJZostjJrJjC6CRTRF0w0Oxn8vhCnwIes2o+aDja5lc0qX/rx2b7iTXzYFAK7ZAI EAuQ== X-Gm-Message-State: AN3rC/5eFOktM/RP4msgQUHKij2u8gdYRAYzJkBs2eNYK8iaEvKMGplG ceUGq94V8OV1azbpsyk= X-Received: by 10.98.86.75 with SMTP id k72mr10316463pfb.215.1493368575196; Fri, 28 Apr 2017 01:36:15 -0700 (PDT) Date: Sun, 01 Jan 2017 00:00:00 -0000 From: Alan Modra To: Florian Weimer Cc: Cary Coutant , Sriraman Tallam , gnu-gabi@sourceware.org, binutils , Xinliang David Li , Sterling Augustine , Paul Pluzhnikov , Ian Lance Taylor , "H.J. Lu" , Rahul Chaudhry , Luis Lozano , Rafael =?iso-8859-1?Q?Esp=EDndola?= , Peter Collingbourne , Rui Ueyama Subject: Re: Reducing code size of Position Independent Executables (PIE) by shrinking the size of dynamic relocations section Message-ID: <20170428083609.GA24006@bubble.grove.modra.org> References: <4f55a033-0e81-e83c-31d0-9e54813528ab@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4f55a033-0e81-e83c-31d0-9e54813528ab@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2017-q2/txt/msg00010.txt.bz2 On Fri, Apr 28, 2017 at 08:25:04AM +0200, Florian Weimer wrote: > 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. That's true for GOT entry relocations, but difficult for anything not linker generated. However, the GOT doesn't tend to have too many entries with relative relocs. What's more, it is better to teach the linker how to edit code using such entries from GOT indirect to GOT pointer relative and thus eliminate the GOT entry entirely.. I'm in favour of a very simple compression scheme, perhaps just using a new relocation to adjust an array of words by the base address. From looking at a few random binaries it seems that many relative relocations apply to a run of consecutive words. Of course, using such a simple scheme spoils the fun of designing something entirely new. ;-) > 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 -- Alan Modra Australia Development Lab, IBM