| Message ID | 1348272087-29608-4-git-send-email-scottwood@freescale.com |
|---|---|
| State | RFC |
| Headers | show |
Hi Scott, On Fri, 2012-09-21 at 19:01 -0500, Scott Wood wrote: > This was introduced by commit 244615197469dd6fe75ae082f38424b97c79aeaf, but it > fails in a minimal SPL build where the only thing in arch/powerpc/lib is > cache.c, which apparently doesn't generate any fixup records. > > If this check is really still needed, it should be moved somewhere more > appropriate, but given that it's been three years and no other > architecture does a test like this, I think we can remove it. It would > have been nice if the original commit said how old the problematic > toolchains were. There was a discussion about it a long while back that has some version information: http://www.mail-archive.com/u-boot@lists.denx.de/msg21415.html Based on my testing I only could reproduce the issue with 3.x versions, which are 7+ years old. Best, Peter
On Mon, Sep 24, 2012 at 01:47:27PM -0500, Scott Wood wrote: > On 09/24/2012 10:30:48 AM, Peter Tyser wrote: > >Hi Scott, > > > >On Fri, 2012-09-21 at 19:01 -0500, Scott Wood wrote: > >> This was introduced by commit > >244615197469dd6fe75ae082f38424b97c79aeaf, but it > >> fails in a minimal SPL build where the only thing in > >arch/powerpc/lib is > >> cache.c, which apparently doesn't generate any fixup records. > >> > >> If this check is really still needed, it should be moved > >somewhere more > >> appropriate, but given that it's been three years and no other > >> architecture does a test like this, I think we can remove it. > >It would > >> have been nice if the original commit said how old the problematic > >> toolchains were. > > > >There was a discussion about it a long while back that has some > >version > >information: > >http://www.mail-archive.com/u-boot@lists.denx.de/msg21415.html > > > >Based on my testing I only could reproduce the issue with 3.x > >versions, > >which are 7+ years old. > > So do you think we still need this check (moved to someplace we can > be sure will generate fixups), or is it time to remove it? On ARM, when we build in THUMB mode we make sure to have a new enough gcc to produce a working binary. Maybe given the age of the broken toolchains adding something like the checkthumb rule in Makefile and arch/arm/config.mk and failing on too old would be right?
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index cdd62a2..6e92005 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -75,12 +75,6 @@ TARGETS += $(LIB) all: $(TARGETS) $(LIB): $(obj).depend $(OBJS) - @if ! $(CROSS_COMPILE)readelf -S $(OBJS) | grep -q '\.fixup.*PROGBITS';\ - then \ - echo "ERROR: Your compiler doesn't generate .fixup sections!";\ - echo " Upgrade to a recent toolchain."; \ - exit 1; \ - fi; $(call cmd_link_o_target, $(OBJS)) $(LIBGCC): $(obj).depend $(LGOBJS)
This was introduced by commit 244615197469dd6fe75ae082f38424b97c79aeaf, but it fails in a minimal SPL build where the only thing in arch/powerpc/lib is cache.c, which apparently doesn't generate any fixup records. If this check is really still needed, it should be moved somewhere more appropriate, but given that it's been three years and no other architecture does a test like this, I think we can remove it. It would have been nice if the original commit said how old the problematic toolchains were. Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: Peter Tyser <ptyser@xes-inc.com> --- arch/powerpc/lib/Makefile | 6 ------ 1 file changed, 6 deletions(-)