[U-Boot] Relocation size penalty calculation

J. William Campbell
2009-10-09T00:09:36Z

Joakim Tjernlund wrote:
>> On Fri, Oct 9, 2009 at 9:27 AM, J. William Campbell
>> <jwilliamcampbell@comcast.net> wrote:
>>
>>> Graeme Russ wrote:
>>>
>>>> On Fri, Oct 9, 2009 at 2:58 AM, J. William Campbell
>>>> <jwilliamcampbell@comcast.net> wrote:
>>>>
>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>> Hi Graeme,
>>>>> I would be interested in a third option (column), the x86 build with
>>>>> just -mrelocateable but NOT -fpic. It will not be definitive because
>>>>> there
>>>>> will be extra code that references the GOT and missing code to do some of
>>>>> the relocation, but it would still be interesting.
>>>>>
>>>>>
>>>> x86 does not have -mrelocatable. This is a PPC only option :(
>>>>
>>>>
>>> Hi Graeme,
>>> You are unfortunately correct. However, I wonder if we can get
>>> essentially the same result by executing the final ld step with the
>>> --emit-relocs switch included. This may also include some "extra" sections
>>> that we would want to strip out, but if it works, it could give all
>>> ELF-based systems a way to a relocatable u-boot.
>>>
>>>
>> I don't think --emit-relocs is necessary with -pic. I haven't gone through
>> all the permutations to see if there is a smaller option, but gcc -fpic and
>> ld -pie creates enough information to perform relocation on the x86
>> platform
>>
>
>
It is true that --emit-relocs is not required when -pic and -pie are
used instead. However, pic and pie are designed to allow shared code
(libraries) to appear at different logical addresses in several
programs without altering the text. This is grand overkill for what we
need, which is the ability to relocate the code. The -pic and -pie code
will be larger than the code without pic and pie. How much larger is a
good question. On the PPC, it is larger but not much larger, because
there are lots of registers available and one is almost for sure got (no
pun intended) the magic relocation constant(s) in it. On the 386 with
many fewer registers, pic and pie will cause the code to be
percentage-wise larger than on the PPC. Thus avoiding pic and pie is a
Good Thing in most cases.
> Try -fvisibility=hidden
>
I assume the -fvisibility=hidden is suggested in order to reduce
(eliminate) the symbol table from the output, which we don't need
because there are assumed to be no undefined symbols in our final ld. If
that works, great! I was assuming we might need a custom "strip" program
to delete any sections that we don't need, but this sounds easier if it
gets them all.

Best Regards,
Bill Campbell
> Jocke
>
>
>
>