>>> On 18.02.11 at 00:07, Jakub Jelinek <ja...@redhat.com> wrote: > 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).
For relocations where the relocated field is large enough, considering chained relocations (as seen in NetWare NLMs) would also be a possibility, i.e. r_offset specifies just the first relocation that all need the same addend (and eventual other properties), and the relocated field holds the r_offset of the next field to be relocated. Jan