Haavard Skinnemoen wrote:
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?
No, he is talking about the u-boot ELF file before we strip off the relocation information in converting it to a .bin file. All ELF files contain enough relocation information to relocate the binary. If there are undefined symbols, it my not work, but it can be relocated.
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.
The above statement is not correct. -fPIC is a compiler option requesting the compiler generate Position Independent Code. This involves adding code to relocate all references at execution time, not at load time. This makes the binary larger and slower in exchange for it running anywhere in the address space. The problem remaining with -fPIC on the PPC architecture is that certain operations still must be performed at load time. The GOT is part of the structure required to do this. It may be that we do not completely know all the things that the compiler expects to be done at load time, or it may be that with Grant's work and the correct compiler switches (-mrelocateable) we may know for the PPC. The C compiler produces relocatable code by default, but not PIC. It is true that the Linux loader can relocate ELF code "on the fly" as it loads into memory, PIC or not.
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.
This is correct, the loader allows only "simple" relocations. Basically, the loader is doing the relocations done by the GOT if the code is PIC. The loader is not real complex. The problem is that for u-boot, the loader would need to run either at a fixed location or be itself relocated, which is a chicken and egg problem.
There is a problem with assuming that -fPIC is the way to go on all architectures. First, on some computers, such as IA32 for examples, it is just not practical. There are too few registers to dedicate one register to always containing a relocation value to be added to all references dynamically. There are other examples where the concept of PIC is equally problematic for various reasons. Second, since PIC is not required for "normal" Linux applications, the compiler is often "buggy" when PIC is specified. Further, PIC is often the last feature that is totally debugged on new architectures, so even if it will eventually work, it often won't do so to begin with.
Therefore, in some cases, the only approach that will work for a completely relocatable u-boot would be a small loader running in pre-assigned fixed memory locations that relocates u-boot to the desired address using the ELF relocation data. The GOT would not be available.
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.
Using the .so approach is lots harder (IMHO) than just a simple loader that moves u-boot and relocates it using ELF data. However, whether the ability to relocate u-boot to an arbitrary address is worth the effort is probably in the eye of the beholder. I think that there are more architectures that do not support relocation than actually do support relocation these days. Anybody that uses some kind of pre-loader, like Xilinx or Blackfin, probably has to know the memory size to begin with, so it's not an issue. YMMV
Best Regards, Bill Campbell
Haavard
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users