From: Mike Frysinger Date: Tue, 8 Sep 2009 13:29:35 -0400 Subject: [U-Boot] PowerPC -mrelocatable In-Reply-To: <1252426573.6005.253.camel@localhost.localdomain> References: <4A938C76.9000009@monstr.eu> <4A96C72F.2070806@freescale.com> <1252426573.6005.253.camel@localhost.localdomain> Message-ID: <200909081329.37678.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tuesday 08 September 2009 12:16:13 Peter Tyser wrote: > I did some debug on gcc 3.4.3/binutils2.3.4/glibc2.15 which was a known > non-working setup on an MPC8548-based board. I'm 98% sure the the > reason it fails because it doesn't properly generate .fixup sections. > No .fixup sections are present in any of the compiled objects or u-boot. > This results in the link script variable '__fixup_entries' equalling 0, > so no relocation fixups are performed on bootup (eg see line 943 in > cpu/mpc85xx/start.S). > > It looks like this was a gcc bug that has been fixed: > http://gcc.gnu.org/ml/gcc-cvs/2004-12/msg00057.html > > ... > > My vote would be to find out which version of gcc contains the > relocation bug and spit out an error if gcc < than that version is used. > We could also try and get fancy and dynamically turn on/off relocation > support at compile time based on gcc's version if other's wanted to > maintain support for older compilers. These changes would only be for > ppc at this point btw. or run readelf on the objects that are known to not generate fixup stuff and error out if they're missing in the objects ? -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20090908/a6ff89a6/attachment.pgp