Hello Graeme, On Wed, 04 Feb 2015 18:14:22 +1100, Graeme Russ <gr...@tss-engineering.com> wrote: > Hi Guys, > > Since I did the initial 'full relocation' for x86 way back when > (http://git.denx.de/?p=u-boot.git;a=commit;h=1c409bc7101a24ecd47a13a4e851845d66dc23ce), > > there has been a lot of chatter about the ongoing need for > CONFIG_NEEDS_MANUAL_RELOC. I think it's about time we looked really hard > at this define and come to a definitive conclusion as to IF and HOW we > can get rid of it for the remaining architectures that use it (being > avr32, m68k, nds32, and sparc).
I second that. > First, a bit of a primer on why and how I finally killed off > CONFIG_NEEDS_MANUAL_RELOC for x86... > > Despite the best intentions of the 'manual' relocation performed by > U-Boot, there were still instances where the U-Boot binary referenced > the 'unrelocated' image which typically resides in flash (NOR flash in > the case of the x86 board I was using). I only finally tracked this down > through some arduous debugging of random crashes during the writing of a > new U-Boot image to the NOR flash. > > After a lot of digging around, I managed to get a good understanding of > the ELF binary format for x86 and compiler/linker flags needed in order > to generate a binary image that could be relocated. It turns out that > for x86, it was the -pic and --emit-relocs ld flags (Oddly, I cannot > find the -pic flag in the gnu ld documentation maybe it's depricated?) When I did the ELF relocation for ARM, only -pie existed for ld; but it has an alias, --pic-executable. Maybe -pic is short for -pic-executable? > The --emit-relocs flags leaves the relocation sections (for x86 the > section of interest is .rela.dyn) in the final image. These sections > list all the locations in the final binary that need to be adjusted if > the image is loaded at a different address than the one it is compiled > for. You can see the processing in do_elf_reloc_fixups() in > arch/x86/lib/relocate.c For ARM I just specified the placement of relocation sections in the linker script; I'm surprised that x86 needs this --emit-relocs. Maybe that's needed when one does not provide a custom linker script? > Keep in mind that the relocation sections are NOT copied to RAM - they > are only used once after U-Boot is copied to RAM to locate the memory > locations that need to be adjusted. > > So the crux of generic relocation is to generate a stripped binary with > all necessary ELF relocation information located AFTER the text and data > sections which are copied to RAM > > So the first question that we need to answer is: Do the avr32, m68k, > nds32, and sparc toolchains support the generation of the relevant > sections needed to perform relocation in a manner similar to x86 (i.e > generation of relocation references into sections of the final U-Boot > binary)? Those arches which use GCC should be able to use -pie / -pic-executable and possibly --emit-relocs, as none of these is arch-specific. Then, each arch might have to look into what GCC options are needed. For the record, on ARM, I did not need any gcc option, but actually had one -fPIC option /removed/. > Regards, > > Graeme Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
