From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Fri, 25 Jul 2008 15:03:43 -0400 Subject: [U-Boot-Users] Changing u-boot relocation scheme In-Reply-To: <20080725205017.564dedff@siona.local> References: <20080724185734.6d79c419@hskinnemo-gx745.norway.atmel.com> <20080725042816.4F8B1248A5@gemini.denx.de> <20080725111041.4c0b925a@siona.local> <1216986958.17719.13.camel@duo> <20080725141909.4a635af0@siona.local> <1216996436.7972.14.camel@duo> <4889EF68.7090108@ge.com> <20080725205017.564dedff@siona.local> Message-ID: <488A238F.5010806@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Haavard Skinnemoen wrote: > On Fri, 25 Jul 2008 11:21:12 -0400 > Jerry Van Baren wrote: > >> The relocation information is in the ELF file until and unless we remove >> it. "Normal" ELF executables retain that relocation information... that >> is exactly what the "L" (it) is for. The linux loader (elf loader) >> loads an executable into an arbitrary memory location and relocates it >> by fixing up addresses based on the relocation table. > > You're mixing two different relocation tables. Statically linked > executables (like u-boot) normally don't have any relocation > information in them after they are fully linked. Dynamically linked > executables, position-independent executables (PIE) and shared > libraries have dynamic relocations which are not only in the ELF file, > but in a loadable segment so that they can be accessed at run time. > > The relocation information from the .o files are not preserved in the > final executable unless you specify the --emit-relocs flags, which > exists purely for debugging purposes. The relocations used by the > dynamic loader come from an entirely different, simpler set of > relocation types which are normally not found in .o files. > > Why do you think objdump has two different options for dumping normal > (-r) vs. dynamic (-R) relocations? > > And no, Linux ELF executables can _not_ be loaded into an arbitrary > memory location unless they are PIE. Shared libraries, however, can be > loaded at arbitrary memory locations, though things like pre-linking > might make it more optimal to try to place them at the same address > everywhere. Thanks for the explanation. I have not worked at this level with executable formats in a long time. My experience harks back to Z80 formats (I forgot which, but post-CPM which loaded into a fixed address) and .COM and .EXE formats which have rudimentary relocation fixup information so that they could be run at arbitrary addresses. Those are non-virtual (or didn't use the MMU) formats, equivalent to your PIE reference. > Ok, I'll stop the chest-beating now. But please stop trying to tell > people that adding a powerpc-specific option (which nobody seems to > know how really works) to the command line will work on any other > architectures than powerpc. Fair enough. > Haavard Discovering my banner is labeled "obsolete", gvb