This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Reducing code size of Position Independent Executables (PIE) by shrinking the size of dynamic relocations section
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Rahul Chaudhry <rahulchaudhry at google dot com>, Cary Coutant <ccoutant at gmail dot com>, Sriraman Tallam <tmsriram at google dot com>, Rahul Chaudhry via gnu-gabi <gnu-gabi at sourceware dot org>, Suprateeka R Hegde <hegdesmailbox at gmail dot com>, David Edelsohn <dje dot gcc at gmail dot com>, Rafael Avila de Espindola <rafael dot espindola at gmail dot com>, Binutils Development <binutils at sourceware dot org>, Alan Modra <amodra at gmail dot com>, Xinliang David Li <davidxl at google dot com>, Sterling Augustine <saugustine at google dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Ian Lance Taylor <iant at google dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Luis Lozano <llozano at google dot com>, Peter Collingbourne <pcc at google dot com>, Rui Ueyama <ruiu at google dot com>, llvm-dev at lists dot llvm dot org
- Date: Sun, 07 Jan 2018 11:31:10 +0100
- Subject: Re: Reducing code size of Position Independent Executables (PIE) by shrinking the size of dynamic relocations section
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvnynFwXFGLj3tAVgDatn0zmuHcWHyRNuDvR+wRZCXLnar_A@mail.gmail.com> <8737cosnym.fsf@localhost.localdomain.i-did-not-set--mail-host-address--so-tickle-me> <CAGWvnynEe3QkhDMGc=Tx8Vr44egtv3xLuh1yiVcAhv+e3GLtZg@mail.gmail.com> <a3e5c76c-8cb9-fc53-a30a-96b2c85079e1@gmail.com> <a68a5d29-09d6-e758-8680-d94f42762adf@redhat.com> <7e698a5f-32d7-6549-7e23-8850b85e6c10@gmail.com> <CAAs8Hmziqc0hebPndiGuZN=buFm=M+O+2fGCfsv_rvDro9zJZA@mail.gmail.com> <CAJRD=ooGubyUOLE6W7LHdeU2ZNDEG1A=84+P=1iOvfmD7-7GNg@mail.gmail.com> <874lozec25.fsf@mid.deneb.enyo.de> <CAAs8HmwMRTjyLjvUAbP9drkagbpedonHOGGRvoFQVr1TE7wyCQ@mail.gmail.com> <CAJRD=opP96vFuSKK-1d1jw3nOKeTDE1T_E5hDwj3Zy-VUeAnRA@mail.gmail.com> <CAORpzuMftCGpXUObOyoFY0=jorMBDWEDbQJ23DifTNW3v-WA6Q@mail.gmail.com> <CAJRD=opERJszwQMFfaKMVdOYF-YAbqqYW0iNWWMqNp3pq2njzw@mail.gmail.com> <CAJimCsHJ9H0uhMbrAZm-BS_VpYggv21ENJm7Q56LTOqC4scYnQ@mail.gmail.com> <CAJRD=oodUsXaRf6trNnN7-=9TFrqQFjeM_TviPPfFWoMPkzmGA@mail.gmail.com> <CAORpzuPYsSBJtypm3NDcfcgRzos3WO4JjkvgiqpyBYBhoqLVFA@mail.gmail.com>
* Roland McGrath:
> Given this corpus of "reloc traces" you can code up many competing encoding
> formats and do serious measurements of their space savings across the
> entire corpus from simple simulations without having to implement each
> encoding in an actual toolchain and dynamic linker to do the analysis.
On the other hand, the linker currently assumes that the order in
which relative relocations are emitted does not matter. With a
different encoding scheme, future linkers might reorder the
relocations or data objects themselves, either to reduce relocation
encoding size, or to make relocations more efficient (perhaps to
support vectorization). Unfortunately, the numbers which can be
derived from ET_DYN files will not reflect to what extent such
reordering is possible.