<p dir="ltr">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 .<a href="http://data.rel.ro">data.rel.ro</a> and such section names, but certainly nothing particularly to encourage patterns of relocation offsets beyond e.g. simple contiguity of vtables.</p>
<br><div class="gmail_quote"><div dir="ltr">On Sun, Jan 7, 2018, 02:31 Florian Weimer <<a href="mailto:fw@deneb.enyo.de">fw@deneb.enyo.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Roland McGrath:<br>
<br>
> Given this corpus of "reloc traces" you can code up many competing encoding<br>
> formats and do serious measurements of their space savings across the<br>
> entire corpus from simple simulations without having to implement each<br>
> encoding in an actual toolchain and dynamic linker to do the analysis.<br>
<br>
On the other hand, the linker currently assumes that the order in<br>
which relative relocations are emitted does not matter.  With a<br>
different encoding scheme, future linkers might reorder the<br>
relocations or data objects themselves, either to reduce relocation<br>
encoding size, or to make relocations more efficient (perhaps to<br>
support vectorization).  Unfortunately, the numbers which can be<br>
derived from ET_DYN files will not reflect to what extent such<br>
reordering is possible.<br>
<br>
</blockquote></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature"><p dir="ltr"><br>
Thanks,<br>
Roland</p>
</div>