From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joakim Tjernlund Date: Fri, 25 Jul 2008 15:30:21 +0200 Subject: [U-Boot-Users] Changing u-boot relocation scheme In-Reply-To: <20080725141909.4a635af0@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> Message-ID: <013a01c8ee5a$966d6c40$c34844c0$@Tjernlund@transmode.se> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > -----Original Message----- > From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-bounces at lists.sourceforge.net] > On Behalf Of Haavard Skinnemoen > Sent: den 25 juli 2008 14:19 > To: kenneth johansson > Cc: vb; u-boot-users at lists.sourceforge.net; Wolfgang Denk > Subject: Re: [U-Boot-Users] Changing u-boot relocation scheme > > On Fri, 25 Jul 2008 13:55:58 +0200 > kenneth johansson 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. > > And if the ELF file wasn't compiled as position-independent code to > begin with, there's just no way it will ever work if it's loaded at a > different address than it was linked at. You can't go through and fix > up all the compiler-generated address calculations when you don't even > have a clue where they are! > > So whether or not the u-boot ELF file has everything we need depends a > _lot_ on what options were used when building it. Exactly. > > > 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). I think the best bet is to make -mrelocatable work for PPC. Question is how does the other arches do it? Do they include fixup ptrs by default or do they lack this functionality? Jocke > > Haavard