[U-Boot-Users] Changing u-boot relocation scheme

[J. William Campbell]

Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 22:51:09 +0200
> kenneth johansson <kenneth at southpole.se> wrote:
>
>   
>>> Hmm...looks like linking with -pie (or --pic-executable) does
>>> something vaguely resembling the trick. But I don't know what vintage
>>> of ld you need for this to be available and actually work...  
>>>       
>> Can't see any reason for using this flag over -fPIC for a program like
>> u-boot.
>>     
>
> You need both. One is a compiler flag, the other is a linker flag. The
> linker will probably barf if you try to create a PIC executable from
> modules that were not compiled with -fPIC.
>   
No, it won't. You just get a module with a lot more relocations to do. I 
have verified that all four possible combinations of the compiler -fPIC 
and linker -pie work and make sense. FWIW, -fPIC code on IA32 is about 
16% larger than non-PIC code, while on the Blackfin, -fPIC code is about 
2% larger than non-PIC code. This is an average over several large C++ 
applications.


> On the other hand, using -fPIC but not -pie takes us about 95% of the
> way to a fully relocatable u-boot, and is what PowerPC, AVR32 and
> others are doing today. The remaining cases -- static and global
> initialized pointers -- are fixed up manually.
>
> If we link with -pie and add a bit of code to handle the dynamic
> relocations, we could get rid of the manual fixups. I don't know if the
> result would be larger or smaller than what we have today, but it would
> probably be a bit more robust.
>   
I agree with this suggestion. This is the only way to ensure a "sane" 
environment, because it emulates what the compiler expects to happen. 
Looping over all the relocation entries and doing the "right thing" is 
architecture specific, but the process is general. The GOT entries can 
also be processed this way. Effort spent on this approach will tend to 
be more generic than the current PPC specific approach.
>   
>>> Does this really work without any relocation? Or is it being relocated
>>> and I'm just too blind to see it?  
>>>       
>> No you are right there is probably many places like this. the code just
>> use the old location and that works most of the time.
>>     
>
> Ah, of course. The strings are probably read directly from flash.
>   
Maybe not. I have been looking at assembly dumps of short examples on 
the IA32 built with -fPIC. It is clear that the method of addressing 
static variables and static constants is DIFFERENT from the method used 
for global variables. The relationship of the location of the text 
segment (executable code), the GOT data, and the static 
variables/constants must remain fixed. The location of the entire 
program can move, but it must move in one piece. If it does move as one 
piece, the lea (load effective address) instructions relative to the GOT 
pointer will be relocated to the new address correctly. These references 
are based totally on the offset from the point of reference. If the code 
is similar on your platform (which I bet it is), then the reference will 
not be to the flash but rather the "new" place where the data was 
moved.. Global variables, however are referenced indirectly via 32 bit 
address pointers in the GOT, and these addresses must be relocated by 
the "loader".
The "loader" also must relocate any initialized pointers, because the 
program itself does not. It would be interesting to know how this is 
accomplished, via what relocation codes, but it does happen.

Best Regards,
Bill Campbell
> Haavard
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>
>