[U-Boot] ARM relocation, question to Heiko

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 03/10/2010 17:36, J. William Campbell a ?crit :

> 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

Hi Bill,

Thanks for the explanations. I am experimenting with ELF relocation 
right now, replacing -fPIe with -pie, and this generates .rel.dyn, but 
also many other sections. I'm trying to get rid of them; apparently 
/DISCARD/ing them in the linker file seems to reduce this to a minimum 
(I still have a .got.plt section which seems useless but I cannot remove 
it lest the linker segfaults).

But the .rel.dyn generated by the linker section does not provide 
symbols to mark its start and end, and I have found no documentation in 
binutils ld which would describe how to rewrite the .rel.dyn section and 
add these symbols myself.

How did you manage that for i386? I did not see a linker file in the 
i386 part of u-boot.

Amicalement,
-- 
Albert.