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

[Haavard Skinnemoen <haavard.skinnemoen@atmel.com>]

On Sat, 26 Jul 2008 14:29:35 -0700
"J. William Campbell" <jwilliamcampbell@comcast.net> wrote:
> Haavard Skinnemoen wrote:
> > On Fri, 25 Jul 2008 22:51:09 +0200
> > kenneth johansson <kenneth@southpole.se> wrote:    
> >> 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.

On some platforms it will. Text relocations are nasty, so some
platforms (e.g. avr32) just refuse to deal with them. But that's not
really relevant -- each architecture should decide whether to compile
with -fPIC or not.

> 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.

Right...that's counting the whole loadable image or just the .text
section? Not suprising that a modern architecture like Blackfin likes
-fPIC a lot better than an old beast like i386 though.
 
> 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.

Right...I think the GOT entries already are processed this way, sort of.

> > 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..

Yes, address calculations in the code should be correct, as the whole
thing was compiled with -fPIC. Data references, however, are usually
not. The code being discussed here is an array of pointers to strings.
I'm pretty sure the pointers are still pointing to flash after
relocation.

> Global variables, however are referenced indirectly via 32 bit 
> address pointers in the GOT, and these addresses must be relocated by 
> the "loader".

The global variables themselves are accessed through the GOT, yes. But
the _value_ of a global variable is currently not relocated
automatically.

> 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.

This is what's currently being done manually by adding a fixed offset
to all the pointers we "know" need to be relocated. When linking with
-pie, these initialized pointers will get a dynamic relocation entry
each so that we can replace all these manual fixups by simply iterating
over the relocations.

To summarize: Address calculations in executable code do not need to
change since we already compile with -fPIC. Initialized pointers,
however, are currently handled in a very suboptimal way, and linking
with -pie might be one piece of the solution to this.

Haavard