Re: x32 psABI draft version 0.2

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Feb 17, 2011 at 11:49:56PM +0100, Jan Hubicka wrote:
> The blog claims
> Architecture 	libxul.so size 	relocations size 	%
> x86 	21,869,684 	1,884,864 	8.61%
> x86-64 	29,629,040 	5,751,984 	19.41%
> 
> The REL encoding also grows twice for 64bit target?
> 
> > REL.  There might be better ways how to get the numbers down.
> 
> These are difficult since they mostly come from vtables and we need to be
> pretty smart to optimize vtable out completely.  Mozilla recently started to
> use elfhack (in official builds) that is sort of their own dynamic linker
> handling PC relative relcoations only.  Pretty ugly IMO but they claim 16%
> savings on x86-64, 6% on x86

By better ways I meant create new relocations for relative relocs that would
be even more compact (assuming we can't or don't want to change the fact
that vtables contain pointers instead of pc relative pointers and assuming
Mozilla doesn't want to change implementation language to something saner
than C++ ;) ).
On my libxul.so I see:
 0x000000006ffffff9 (RELACOUNT)          161261
Relocation section '.rela.dyn' at offset 0x75a10 contains 186467 entries:
Relocation section '.rela.plt' at offset 0x4ba358 contains 4722 entries:
so all that it actually matters there are relative relocations.
So one way to cut down the size of .rela.dyn section would be a relocation
like
R_X86_64_RELATIVE_BLOCK where applying such a relocation with r_offset O and
r_addend N would be:
uint64_t *ptr = O;
for (i = 0; i < N; i++)
  ptr[i] += bias;
Then e.g.
0000003ec6d86008  0000000000000008 R_X86_64_RELATIVE                               0000003ec5aef3f3
0000003ec6d86010  0000000000000008 R_X86_64_RELATIVE                               0000003ec5af92f6
0000003ec6d86018  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b06d17
0000003ec6d86020  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b1dc5f
0000003ec6d86028  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b1edaf
0000003ec6d86030  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b27358
0000003ec6d86038  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b30f9f
0000003ec6d86040  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b3317d
0000003ec6d86048  0000000000000008 R_X86_64_RELATIVE                               0000003ec5b34479
could be represented as:
0000003ec6d86008  00000000000000MN R_X86_64_RELATIVE_BLOCK                         0000000000000009
I see many hundreds of consecutive R_X86_64_RELATIVE relocs in libxul.so, though
of course it would need much better analysis over larger body of code.

In most programs if the library is prelinked all relative relocs are skipped
and .rela.dyn for them doesn't need to be even paged in, but Mozilla is quite
special in that it one of the most common security relevant packages and thus
wants randomization, but is linked against huge libraries, so the question is
if Mozilla is the right candidate to drive our decisions on.

Another alternative to compress relative relocations would be an indirect
relative relocation, which would give you in r_offset address of a block of addresses
and r_addend the size of that block, and the block would just contain offsets
on which words need to be += bias.  Then, instead of changing RELA to REL to
save 8 bytes from 24 you'd save 16 bytes from those 24 (well, for x32 half of that).

	Jakub