This is the mail archive of the
mailing list for the GCC project.
Re: x32 psABI draft version 0.2
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
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;
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).