[U-Boot] ARM relocation, question to Heiko

[J. William Campbell]

  On 10/3/2010 1:58 AM, Albert ARIBAUD wrote:
> Le 03/10/2010 10:44, Graeme Russ a écrit :
>
>>> Bill just said that -pic (or, for ARM, -fPIC or -fPIE) was unnecessary
>>> for relocation. You seem to imply it actually is... In my experience,
>>> -fPIC and-fPIE do increase code by adding GOT relocation to symbols 
>>> that
>>> need fixing, so they would indeed be redundant to any other relocation
>>> mechanism -- I just did some test with basic code and this seems to
>>> confirm, no -fPIx is needed to get relocation the way you do on ARM.
>>
>> Just to clarify -fpic is a compiler option, -pic is a linker option. x86
>> has no compile time relocation options (therefore no referencing .got 
>> etc).
>> Using the link time pic option produces the relocation data table
>> (.rel.dyn) which must be pre-processed before execution can begin at the
>> relocated address
>
> Thanks for clarifying, Graeme.
>
> This is consistent with the ARM compile-time options -fPIC/-fPIE vs 
> link-time option -pie. So there may be at least an interest in 
> investigating ELF-style relocation on ARM and comparing it to 
> GOT-based relocation in terms of FLASH and RAM sizes and code speed.
>
Hi All,
       It is for sure that -fPIC/-fPIE programs will contain more 
executable instructions than programs compiled without these options.
The program will also contain more data space for the got. If -fPIC 
actually produced a fully position-independent executable, the extra 
overhead would perhaps be tolerable. However, since it does not do this, 
(problems with initialized data etc.) there is really no advantage in 
using these compile-time options. The executable code and required data 
space for the program without these switches will "always" be smaller 
and faster than with them. In order to fix the remaining issues even 
when using -fPIC, a relocation loop must exist in the u-boot code, 
either one global one or a bunch of user written specific ones. Also, 
the -pie switch will be needed anyway at link time to build the 
relocation table for the remaining relocation requirements.
       Programs compiled without -fPIC will have a larger .rel.dyn table 
than those compiled with -fPIC. However, the table entries in the 
relocation table occupy about the same storage as the code generated by 
the compiler to relocate a reference to the symbol at run time.  So this 
is probably a almost a wash. Also, the dynamic relocation data need not 
be copied into the run-time object, as it is no longer needed. So the 
likely outcome is that the "flash" image is about the same size/slightly 
larger than the one compiled by -fPIC, and that the ram footprint after 
relocation is slightly smaller.
       If one is REALLY pressed for space, the size of the dynamic 
relocation area can be reduced by a post-processor program that would 
re-format the relocation entries. This re-formatting is possible because 
1) ELF is a very general format and we only need a small subset of it, 
and 2) u-boot code will never occupy say 16 MB of space, so each 
relocation can probably be compressed into a 32 bit word. I doubt anyone 
is that desperate, but it IS possible.
       It will be interesting to see what the results of this comparison 
are. For me, the no user awareness of relocation is worth a lot, and the 
fact that the difference/overhead of relocation will all be in exactly 
one place is very appealing.

Best Regards,
Bill Campbell
>> Cheers,
>>
>> Graeme
>
> Amicalement,