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.