From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19736 invoked by alias); 14 Dec 2017 08:11:36 -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 19694 invoked by uid 89); 14 Dec 2017 08:11:33 -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=H*Ad:U*davidxl, curious 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-f180.google.com Received: from mail-wr0-f180.google.com (HELO mail-wr0-f180.google.com) (209.85.128.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Dec 2017 08:11:32 +0000 Received: by mail-wr0-f180.google.com with SMTP id y21so4387554wrc.1; Thu, 14 Dec 2017 00:11:32 -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=AIMVa/YqUTScEdCdpQ4+4ApFA5UEsWfkwjNX1rRQaXI=; b=ANEBUQ/gdIQbADmShf0IpaUaLA3o6Qb0oL/7OLwwXitK3XY78JVVl1IZhxm1Dd9W+4 01/MaBDqLYc962+jjZVcKmR05AVXsqZUelJ1yGosVHg2dbqAM55oD1RQxuQwMFhKFUZB 60zb4XmC3SVZhQdBhw33cIbec/5JwXMNGKSSwQDw0MsD0RK2KFQ6N03N9EdqtGrQBMlS 51aFmhsBZ1ibOCg/zwyPdS3f0gTjTC8OBrOSQO85wvJRgfbS3tPD/tcbmWGG/M6jO4Wc xzr2aWvuPXiXhACiBC/p0N39D5j4PkDODR+RkwNqYdPGujxm3hYwWlzpJank9902GOgE 1Grg== 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=AIMVa/YqUTScEdCdpQ4+4ApFA5UEsWfkwjNX1rRQaXI=; b=BVaJ+ThE4RXdz6P+bDfl8FOTrEMD9gW/VB/3wutyiJu9jOSV7/mJc6zmSQTYI+f644 9+8/f4ZWVK7vvVMGt+QixoxF7RmGtfXbT1zdcyIrnfR0QzJzxfELH8mfn9ue7d8nb4Cp zWs4p/nYBhMoqn2n0gG16fc+9RdAhgtNm83yjaSCsv+XajG8xMc8ld4WlSAmXIjJqRig P9jeQdTe54yunm6W9Rmsa4oMDFbn1Fz2Jbg/8UzA7nF75Ph8feaSzvjCAntjJ4bhj0yf Gf9QOfzCYJ63uzIgV/SBT1IBTVcp07gybdLmt3idF83kuYCoCpxyXTJ3fmFXxpWaGIs6 pj5w== X-Gm-Message-State: AKGB3mKj9psvl/hRqT4vNs6+JqafkEaWOz4dQRaOk73Evk3keLCYoJJK HIWiBYTI3eFxUcT3uX/QlxKn7het4AqaMc5oof8= X-Google-Smtp-Source: ACJfBoszFrNjZ9cqwcWOI5ZQG7sNccEeKo3LuLasm9GnnOj4i7DE1D39dtBlK/IdF8BSao/RtQOlfubMLcl0b/y/HyI= X-Received: by 10.223.168.35 with SMTP id l32mr5136156wrc.261.1513239090358; Thu, 14 Dec 2017 00:11:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.150.35 with HTTP; Thu, 14 Dec 2017 00:11:29 -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> <874lozec25.fsf@mid.deneb.enyo.de> 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: Roland McGrath , Sriraman Tallam , Florian Weimer , Rahul Chaudhry via gnu-gabi , Suprateeka R Hegde , Florian Weimer , David Edelsohn , Rafael Avila de Espindola , Binutils Development , Alan Modra , 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/msg00020.txt.bz2 > While adding a 'stride' field is definitely an improvement over simple > delta+count encoding, it doesn't compare well against the bitmap based > encoding. > > I took a look inside the encoding for the Vim binary. There are some instances > in the bitmap based encoding like > [0x3855555555555555 0x3855555555555555 0x3855555555555555 ...] > that encode sequences of relocations applying to alternate words. The stride > based encoding works very well on these and turns it into much more compact > [0x0ff010ff 0x0ff010ff 0x0ff010ff ...] > using stride==0x10 and count==0xff. Have you looked much at where the RELATIVE relocations are coming from? I've looked at a PIE build of gold, and they're almost all for vtables, which mostly have consecutive entries with 8-byte strides. There are a few for the GOT, a few for static constructors (in .init_array), and a few for other initialized data, but vtables seem to account for the vast majority. (Gold has almost 19,000 RELATIVE dynamic relocs, and only about 500 non-RELATIVE dynamic relocs.) Where do the 16-byte strides come from? Vim is plain C, right? I'm guessing its RELATIVE relocation count is fairly low compared to big C++ apps. I'm also guessing that the pattern comes from some large structure or structures in the source code where initialized pointers alternate with non-pointer values. I'm also curious about Roland's app. In my opinion, the data and my intuition both support your choice of a jump + bit vector representation. -cary