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