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

[kenneth johansson <kenneth@southpole.se>]

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. 


> So whether or not the u-boot ELF file has everything we need depends a
> _lot_ on what options were used when building it.

Not really only what info you stripped way in the last linker stage. But
this is going way off topic nobody is really arguing to include a linker
in u-boot so it does not matter what options is available if we did. 

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

And could you outline how the last step in generating the binary image
would work. 

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.  

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

----------------
--- config.mk
+++ config.mk
@@ -215,7 +215,8 @@
 
 AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
 
-LDFLAGS += -Bstatic -T $(LDSCRIPT) $(PLATFORM_LDFLAGS)
+#LDFLAGS += -Bstatic -T $(LDSCRIPT) $(PLATFORM_LDFLAGS)
+LDFLAGS += -Bstatic -shared -T $(LDSCRIPT) $(PLATFORM_LDFLAGS)
 ifneq ($(TEXT_BASE),)
 LDFLAGS += -Ttext $(TEXT_BASE)
 endif