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

[kenneth johansson <kenneth@southpole.se>]

On Fri, 2008-07-25 at 17:23 +0200, Haavard Skinnemoen wrote:
> On Fri, 25 Jul 2008 16:33:56 +0200
> kenneth johansson <kenneth@southpole.se> wrote:
> > 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?

I have before but I just did a quick test to make sure I'm not spreading
miss information. 

ld -Ttext 0x02000000 -Map u-boot_2.map -o u-boot_2 u-boot

at least creates a map file that looks ok for a u-boot compiled both
with -fpic and without. Did not actually run the result. 

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

hmm just checked what objcopy does and it do not work well with a object
file created with shared. the resulting binary do not have .text first
so it's not really workable at least not with that simple patch. 

cant find any option to make objcopy print out what section it actually
writes out in the out file. 

> There will obviously be a fair amount of arch-specific code required to
> make the actual relocation work though.

So the gain of using dynamic relocation is that we have fever relocation
types to implement and objcopy is not going to strip away the relocation
section as it do for non dynamic relocs. 

still the code to actually do the relocation is architecture dependent
and non existing. At least for powerpc we have a much easier option of
having gcc generate a fixup table.