On Wed, Oct 7, 2009 at 5:55 PM, Wolfgang Denk wd@denx.de wrote:
Dear Graeme Russ,
In message d66caabb0910061824s4165d33bu5d5213f6783c09d0@mail.gmail.com you wrote:
I think that even the -mrelocatable / .fixup method may not be needed at all. -pie / -pic used by themselves creates enough information for an OS dynamic loader to relocate an executable, so why not U-Boot? Given that the type and location of each section is easily determined, a striped down dynamic loader can provide a platform-independent relocation scheme.
One reason for not using ELF images for the boot loader is size. The ELF header alone is often more than we would be willing to accept, not to mention the additional code.
But the headers get stripped from the final binary. All we are left with in order to locate the ELF section data are the symbols exported from the linker script
The extra code is only three very tight for-loops. I had them wrapped in functions to improve readability, but they are good inline candidates (only called once each) and I doubt they use much code space at all (I'll send through actual numbers soon)
But how much space in the extra sections you link in?
if size is comparable with fixup ptrs we should probably consider using the same for ppc. Then we can use -fpic/-fpie and that is significantly smaller then -fPIC on PPC.
Question is, does -mrelocatable result in smaller .got (et al) are is the .fixup section adding extra size for the sake of ease of implementation?
fixup section expands with lots of ptrs, then fixup is placed just after .got