[llvm-dev] Reducing code size of Position Independent Executables (PIE) by shrinking the size of dynamic relocations section

Roland McGrath via llvm-dev llvm-dev at lists.llvm.org
Sun Jan 7 02:50:32 PST 2018


Currently the relocation entries are sorted by address (-z combreloc), but
that's irrelevant since I extract all the individual addresses for the
traces to feed encoding analyses and the new encodings we're talking about
entail exactly things like how you order the addresses to be relocated.
Link time reordering of data itself to make the data's relocation needs
more patterned is conceivable I suppose.  In practice today it has some
locality by dint of .data.rel.ro and such section names, but certainly
nothing particularly to encourage patterns of relocation offsets beyond
e.g. simple contiguity of vtables.

On Sun, Jan 7, 2018, 02:31 Florian Weimer <fw at deneb.enyo.de> wrote:

> * 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.
>
> --


Thanks,
Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180107/ee09a27f/attachment.html>


More information about the llvm-dev mailing list