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,
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
