[U-Boot] Relocation size penalty calculation

[J. William Campbell]

Peter Tyser wrote:
> On Thu, 2009-10-08 at 08:53 -0700, J. William Campbell wrote:
>   
>> Peter Tyser wrote:
>>     
>>> On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote:
>>>   
>>>       
>>>> Out of curiosity, I wanted to see just how much of a size penalty I am
>>>> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are
>>>> the results (fixed width font will help - its space, not tab, formatted):
>>>>
>>>> Section             non-reloc     reloc
>>>> ---------------------------------------
>>>> .text                000118c4  000137fc <- 0x1f38 bytes (~8kB) bigger
>>>> .rodata              00005bad  000059d0
>>>> .interp              n/a       00000013
>>>> .dynstr              n/a       00000648
>>>> .hash                n/a       00000428
>>>> .eh_frame            00003268  000034fc
>>>> .data                00000a6c  000001dc
>>>> .data.rel            n/a       00000098
>>>> .data.rel.ro.local   n/a       00000178
>>>> .data.rel.local      n/a       000007e4
>>>> .got                 00000000  000001f0
>>>> .got.plt             n/a       0000000c
>>>> .rel.got             n/a       000003e0
>>>> .rel.dyn             n/a       00001228
>>>> .dynsym              n/a       00000850
>>>> .dynamic             n/a       00000080
>>>> .u_boot_cmd          000003c0  000003c0
>>>> .bss                 00001a34  00001a34
>>>> .realmode            00000166  00000166
>>>> .bios                0000053e  0000053e
>>>> =======================================
>>>> Total                0001d5dd  00022287 <- 0x4caa bytes (~19kB) bigger
>>>>
>>>> Its more than a 16% increase in size!!!
>>>>
>>>> .text accounts for a little under half of the total bloat, and of that,
>>>> the crude dynamic loader accounts for only 341 bytes
>>>>
>>>> Have any metrics been done for PPC?
>>>>     
>>>>         
>>> Things actually improve a little bit when we use -mrelocatable and get
>>> rid of all the manual "+= gd->reloc_off" fixups:
>>>
>>> 1) Top of mainline on XPedite5370:
>>>    text	   data	    bss	    dec	    hex	filename
>>>  308612	  24488	  33172	 366272	  596c0	u-boot
>>>
>>> 2) Top of "reloc" branch on XPedite5370 (ie -mrelocatable):
>>>    text	   data	    bss	    dec	    hex	filename
>>>  303704	  28644	  33156	 365504	  593c0	u-boot
>>>
>>>   
>>>       
>> Hi Peter,
>>      Just to be clear, the total text+data length of u-boot with the 
>> "manual" relocations (#1)  is LARGER than the text+data length of u-boot 
>> with the "manual" relocations removed and the necessary centralized 
>> relocation code added, along with any additional data sections required 
>> by -mrelocateable (#2), by 768 (dec) bytes?
>>     
>
> Hi Bill,
> Doah, looks like I chose a bad board as an example.  The XPedite5370
> already had -mrelocatable defined in its own
> board/xes/xpedite5370/config.mk in mainline, so the above comparison
> should be ignored as both builds used -mrelocatable.
>
> Here's some *real* results from the MPC8548CDS:
> 1) Top of mainline:
>    text	   data	    bss	    dec	    hex	filename
>  219968	  17052	  22992	 260012	  3f7ac	u-boot
>
> 2) Top of "reloc" branch (ie -mrelocatable)
>    text	   data	    bss	    dec	    hex	filename
>  219192	  20640	  22980	 262812	  4029c	u-boot
>
> So the reloc branch is 2.7K bigger for the MPC8548CDS.
>   
Hi Peter,
     OK, that's more like it! A 1.2 % size increase in ROM seems like a 
very small price to pay for a truly relocatable u-boot image that will 
run on any size memory without the programmer having to actively worry 
about what may need relocating as code is written. . Also, it should be 
noted that the size increase in 2)  is mostly in relocation segments 
that do not need to be copied into ram, so the ram footprint should be 
smaller for 2) than 1). The relocation code itself could also be placed 
is a segment that is not copied into ram, although that may be more 
trouble than it is worth.
       I am looking forward to Graeme's results with the 386. I expect 
that it will not be quite so favorable, perhaps a 4 or 5% size increase 
for -mrelocatable over an absolute build. However, -mrelocatable vs. 
-fpic may be comparable, with -mrelocatable actually winning. But then 
again, I could be totally wrong!

Best Regards,
Bill Campbell
> Best,
> Peter
>
>
>
>