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

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

On Fri, 25 Jul 2008 16:33:56 +0200
kenneth johansson <kenneth@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@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?

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.

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

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

Haavard