Re: x32 psABI draft version 0.2

["Jan Beulich" <JBeulich@novell.com>]

>>> On 18.02.11 at 00:07, Jakub Jelinek <jakub@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