[U-Boot] Relocation size penalty calculation

[Graeme Russ]

On Sat, Oct 17, 2009 at 11:59 PM, J. William Campbell
<jwilliamcampbell at comcast.net> wrote:
> Graeme Russ wrote:
>>
>> On Thu, Oct 15, 2009 at 3:45 AM, J. William Campbell
>> <jwilliamcampbell at comcast.net> wrote:
>>
>>>
>>> Joakim Tjernlund wrote:
>>>
>>
>>
>
> <megasnip>
>

[Yawn... YAS (Yet Another Snip) ;)]

>>
>> The relocation fixup is really easy:
>>
>>        Elf32_Rel *rel_dyn_start = (Elf32_Rel *)&__rel_dyn_start;
>>        Elf32_Rel *rel_dyn_end = (Elf32_Rel *)&__rel_dyn_end;
>>        Elf32_Rel *re;
>>
>>        for (re = rel_dyn_start; re < rel_dyn_end; re++)
>>        {
>>                if (re->r_offset >= TEXT_BASE)
>>                        if (*(ulong *)re->r_offset >= TEXT_BASE)
>>                                *(ulong *)(re->r_offset - rel_offset) -=
>> (Elf32_Addr)rel_offset;
>>        }
>>
>> The size penalty is ~17kB of extra data (which is not copied to RAM) and
>> a tiny amount of relocation code (easily offset by removal of other fixups
>> such as the command table fixup
>>
>> Any without using the pic flag in gcc, there is no GOT and no associated
>> performance penalty.
>>
>> Thanks for everyone's help (especially Jocke and Bill)
>>
>
> Great work Graeme. You have taken a lot of conjecture and guessing and
> converted it to actual truth!
>
> In line with your comment about -fpic, the .text segment size goes from
> 000137fc down to 000118a4, or about an 8 k reduction in size. -fpic also
> contains a .rel_dyn segment, that presumably needs to be processed the same
> way as in the non -fpic case (otherwise, why would it be there?). The size
> of the "residual" .rel_dyn was 00001228, or 4.6 k. This means that the size
> penalty for not using -fpic is only about 3k bytes total in the image, and
> the ram footprint is actually smaller than with -fpic. So now, after

Yes, especially on the x86 because with -fpic, the x86 needs to do a CALL/POP
in the beginning of each function to determine the current IP in order to
calculate absolute addresses using the GOT (ouch!)

> Graeme's work here, it is easily possible to support three different u-boot
> configurations, absolute, relocatable, and relocatable with -fpic. If there
> are any size maniacs out there, we can reduce the size of the relocation
> table at the expense of some post-processing. These days, 9k of flash vs
> 4.5k of flash doesn't seem important, but I imagine if you are right against
> the stops on an existing product it can be very important!
>
> It will be interesting to see similar numbers for other architectures. I
> expect similar results, but you never know. PPC relocation entries are
> larger, so they become more of an issue.
>
> Still more questions for Graeme if he will indulge me! Are the if statements
> in the relocation code ever false? Are there relocations for stuff below
> TEXT_BASE in
> the input binary? If so, do you have any idea why? Not that two if
> statements are a big deal, it is just that I can't explain why there would
> be any relocations below TEXT_BASE, and I can't explain why there would be
> any relocatable references to anything below text base. . I assume this
> might be related to not relocating NULL pointers. That would be reflected in
> the innermost if statement. I would not expect there to be any such
> references, as gas does know the relocation attributes of initialized data,
> and NULL is absolute(?)  Also, if a function is not defined (weak or
> otherwise), the loader should give it an address of absolute 0, which would
> also not generate a relocation entry(?).  It would be interesting to
> intentionally call an un-defined function in u-boot and see if the call ends
> up relocatable. It should not, and if it does we should file a bug report
> for ld!

Apart from NULL pointers, there are some peculiarities for x86 that have
to be dealt with. There are two sections (for BIOS and the real mode
trampoline) which get linked at a hard coded memory location in the low
are of memory (<16M) - The TEXT_BASE checks are to ensure these do not get
trampled.

>
> Thanks again Graeme!
>

NP - Just scratching an itch

> Best Regards,
> Bill Campbell
>>
>> Regards,
>>
>> Graeme
>>
>>
>
>