From mboxrd@z Thu Jan 1 00:00:00 1970 From: kenneth johansson Date: Fri, 25 Jul 2008 19:28:48 +0200 Subject: [U-Boot-Users] Changing u-boot relocation scheme In-Reply-To: <488A0729.1070306@ge.com> 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> <20080725172334.13ee6301@siona.local> <1217003489.7972.33.camel@duo> <488A0729.1070306@ge.com> Message-ID: <1217006928.7972.47.camel@duo> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, 2008-07-25 at 13:02 -0400, Jerry Van Baren wrote: > kenneth johansson wrote: > > On Fri, 2008-07-25 at 17:23 +0200, Haavard Skinnemoen wrote: > > [snip] > > >> 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. > > EVERYTHING *already* exists, we just aren't using it right. That is > what the elf loader does in a "normal" system. Grant did it on the > PowerPC architecture - look at the archives, he didn't write new code > for this, it's already in there. I know exactly what Grant did. But he is not using the elf relocation information as that is simply not included in the data that is the u-boot.bin file. Also this discussion is more about doing it in a way that is not powerpc specific and documented, we already have as you mentioned code for the powerpc specific way but it's not using elf relocation information. I was afraid that what was needed was more or less a complete linker but it looks like if one generate the dynamic reloc table a much simpler linker(relocation function) is needed. Still probably a lot more complex than the GOT and fixup code that is just a loop over a table. We may need a case also ;-)