This is the mail archive of the
mailing list for the binutils project.
Re: Reducing code size of Position Independent Executables (PIE) by shrinking the size of dynamic relocations section
- From: "Sriraman Tallam via binutils" <binutils at sourceware dot org>
- To: Rafael Espíndola <rafael dot espindola at gmail dot com>
- Cc: gnu-gabi at sourceware dot org, binutils <binutils at sourceware dot org>, Xinliang David Li <davidxl at google dot com>, Cary Coutant <ccoutant at gmail 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>, Rahul Chaudhry <rahulchaudhry at google dot com>, Luis Lozano <llozano at google dot com>, Peter Collingbourne <pcc at google dot com>, Rui Ueyama <ruiu at google dot com>
- Date: Thu, 27 Apr 2017 14:21:42 -0700
- 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: <CAAs8HmyKSjqo2GKD0TQy8R80sVcXB3mNORMpXZ_a6sDdmWQOdg@mail.gmail.com> <CAG3jReKcwAOzm9UYmUUHU_peNRoK3u=sLd5FqKaca30zD29bew@mail.gmail.com>
- Reply-to: Sriraman Tallam <tmsriram at google dot com>
On Thu, Apr 27, 2017 at 1:04 PM, Rafael Espíndola
> On 25 April 2017 at 13:12, Sriraman Tallam <firstname.lastname@example.org> wrote:
>> We identified a problem with PIE executables, more than 5% code size
>> bloat compared to non-PIE and we have a few proposals to reduce the
>> bloat. Please take a look and let us know what you think.
> Just a bit of terminology, it is not code, it is a read only data.
> Why is the table size a problem? I can imagine a few reasons, but it
> would be nice to know which one you are trying to solve:
> * The file size itself is a problem for shipping the file.
Yes, this is a problem. Certain binaries go in size sensitive
partitions and this is a blocker.
> * The startup time is a problem and a compact table makes the dynamic
> linker faster.
I think this is useful for Chrome if it improves it. Looking at the
glandium blog seems to suggest it does.
> * The memory usage is a problem.
Yes, this is a problem too.
> For the last one one thing that could be done is have something like
> PT_GNU_RELRO but that tells the dynamic linker to unmmap the region
> completely once it is done with the relocations.
> In addition what is done for COFF, the other existing solution I know
> is https://wiki.mozilla.org/Elfhack. In the case of mozilla the issue
> was just the size of the binary being shipped I think.