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

[J. William Campbell]

Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 16:33:56 +0200
> kenneth johansson <kenneth at southpole.se> wrote:
>
>   
>> On Fri, 2008-07-25 at 14:19 +0200, Haavard Skinnemoen wrote: 
>>     
>>> On Fri, 25 Jul 2008 13:55:58 +0200
>>> kenneth johansson <kenneth at southpole.se> wrote:
>>>
>>>       
>>>>> An ELF shared library has the dynamic relocations we need. So if we
>>>>> build u-boot as an .so file, it should work in theory on most
>>>>> architectures.
>>>>>           
>>>> well the elf binary of u-boot obviously has everything we need
>>>> regardless of what options it was compiled with. If we had a full linker
>>>> at runtime we could just do a relink to whatever address we wanted. 
>>>>         
>>> No we couldn't if we don't have any relocation information. Just as you
>>> can't relink just any ELF binary to run at a different location after
>>> it's been through a final link, no matter how "full" the linker is.
>>>       
>> Take time and READ what people write. I wrote compiler option and you go
>> on about some final link that removes the relocation information. My
>> point was that it is irrelevant if you use pic shared whatever if you
>> are going to use the elf relocation information anyway granted you have
>> less work to do if the object was compiled as PIC. 
>>     
>
> Oh, you're talking about some hypothetical u-boot binary that hasn't
> been through the linker? How exactly do you generate it?
>   
No, he is talking about the u-boot ELF file before we strip off the 
relocation information in converting it to a .bin file. All ELF files 
contain enough relocation information to relocate the binary. If there 
are undefined symbols, it my not work, but it can be relocated.
> Besides, I talked about compiler options too (in the paragraph you cut
> out). If you don't compile the code with -fPIC, most linkers won't be
> able to make the result relocatable no matter what options you specify.
>   
The above statement is not correct. -fPIC is a compiler option 
requesting the compiler generate Position Independent Code. This 
involves adding code to relocate all references at execution time, not 
at load time. This makes the binary larger and slower in exchange for it 
running anywhere in the address space. The problem remaining with -fPIC 
on the PPC architecture is that certain operations still must be 
performed at load time. The GOT is part of the structure required to do 
this. It may be that we do not completely know all the things that the 
compiler expects to be done at load time, or it may be that with Grant's 
work and the correct compiler switches (-mrelocateable) we may know for 
the PPC. The C compiler produces relocatable code by default, but not 
PIC. It is true that the Linux loader can relocate ELF code "on the fly" 
as it loads into memory, PIC or not.
>   
>>>> It sounds a bit easier to just loop over a list of pointers and change
>>>> the values than to implement a complete linker but maybe that is just
>>>> me.
>>>>         
>>> The question remains how should that list of pointers be generated? One
>>> possible answer is to let the linker do it (as dynamic relocations).
>>>       
>> Since I have not done a linker I probably miss some information on what
>> makes the dynamic relocations so special ?? 
>>     
>
> Yes, you probably do. Dynamic relocations are quite special as they are
> intended for the _runtime_ system, not the linker. Therefore, they are
> included in a loadable segment so that the program itself or the
> dynamic loader can go through them and perform fixups at runtime.
>
> Also, most platforms only allow a small handful of relocation types to
> be used as dynamic relocations. This makes the job of the dynamic
> loader much easier than that of the linker.
>   
This is correct, the loader allows only "simple" relocations. Basically, 
the loader is doing the relocations done by the GOT if the code is PIC. 
The loader is not real complex. The problem is that for u-boot, the 
loader would need to run either at a fixed location or be itself 
relocated, which is a chicken and egg problem.

There is a problem with assuming that -fPIC is the way to go on all 
architectures. First, on some computers, such as IA32 for examples, it 
is just not practical. There are too few registers to dedicate one 
register to always containing a relocation value to be added to all 
references dynamically. There are other examples where the concept of 
PIC is equally problematic for various reasons. Second, since PIC is not 
required for "normal" Linux applications, the compiler is often "buggy" 
when PIC is specified. Further, PIC is often the last feature that is 
totally debugged on new architectures, so even if it will eventually 
work, it often won't do so to begin with.

Therefore, in some cases, the only approach that will work for a 
completely relocatable u-boot would be a small loader running in 
pre-assigned fixed memory locations that relocates u-boot to the desired 
address using the ELF relocation data. The GOT would not be available.
>   
>> And could you outline how the last step in generating the binary image
>> would work. 
>>     
>
> That's basically the question I've been trying to ask for some time. On
> PowerPC, I assume -mrelocatable does the trick. On other platforms, I
> just don't know.
>
>   
>> now it works as follows. One final static link with all the .a files and
>> a specified start address for TEXT. result is a elf file with al symbols
>> resolved adn it can be relinked to another address if one wants but we
>> use objcopy to make a binary.  
>>     
>
> Have you ever _tried_ to relink the final u-boot ELF file to another
> address? How do you do that?
>
>   
>> here is a patch to generate dynamic relocations in the elf file. What is
>> the next step? objcopy -j .rela.dyn -O binary  u-boot dyn_reloc_table ??
>>     
>
> Might actually work, though we might need more linker options as well.
> At least -Bsymbolic comes to mind. And I'm not sure if -Bstatic goes
> well along with -shared...
>
> In any case, there's no next step. The dynamic relocations are included
> in a loadable segment, so they will end up in the .bin file after the
> last objcopy step.
>
> There will obviously be a fair amount of arch-specific code required to
> make the actual relocation work though.
>   
Using the .so approach is lots harder (IMHO) than just a simple loader 
that moves u-boot and relocates it using ELF data. However, whether the 
ability to relocate u-boot to an arbitrary address is worth the effort 
is probably in the eye of the beholder. I think that there are more 
architectures that do not support relocation than actually do support 
relocation these days. Anybody that uses some kind of pre-loader, like 
Xilinx or Blackfin, probably has to know the memory size to begin with, 
so it's not an issue. YMMV

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