From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Mon, 20 Feb 2012 21:38:24 +0530 Subject: [U-Boot] [PATCH 2/4] arm: add %function attribute to assembly functions In-Reply-To: <4F3FD679.9030509@aribaud.net> References: <1328528248-20872-1-git-send-email-aneesh@ti.com> <1329314253-4596-3-git-send-email-aneesh@ti.com> <4F3E357E.8080607@ti.com> <4F3F79B4.5060903@aribaud.net> <4F3FA67B.8060603@ti.com> <4F3FD330.7000204@ti.com> <4F3FD679.9030509@aribaud.net> Message-ID: <4F426FF8.3050307@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Saturday 18 February 2012 10:18 PM, Albert ARIBAUD wrote: > Hi Aneesh, > [...] >>> I will get back with more details on the Linaro GCC 2012.01 later. >> >> I meant "the Linaro GCC 2012.01 tool-chain problem" >> >> This is a different problem. Some of the .rodata symbols are given an >> odd address although they should be aligned to at least 2-byte boundary >> ). In fact the data is actually put at the even address but the symbol's >> value is +1 of the actual address. This is the ARM convention for Thumb >> functions, but they have applied it here for data too. That's the >> problem. I see that this doesn't happen to all the .rodata in SPL. >> Neither could I reproduce it with a small program. But the workaround >> for this problem is to avoid -fdata-sections. The following patch works >> around it. >> >> diff --git a/config.mk b/config.mk >> index ddaa477..723286a 100644 >> --- a/config.mk >> +++ b/config.mk >> @@ -190,7 +190,7 @@ CPPFLAGS := $(DBGFLAGS) $(OPTFLAGS) $(RELFLAGS) \ >> >> # Enable garbage collection of un-used sections for SPL >> ifeq ($(CONFIG_SPL_BUILD),y) >> -CPPFLAGS += -ffunction-sections -fdata-sections >> +CPPFLAGS += -ffunction-sections >> LDFLAGS_FINAL += --gc-sections >> endif >> >> Will you take a patch to make -fdata-sections optional, that is, having >> it under something like CONFIG_SYS_SPL_NO_FDATA_SECTIONS? > > Hmm... considering you're seeing the issue in a fairly new toolchain > release, I prefer notifying the toolchain makers, rather than removing > the -fdata-sections from SPL even for specific boards. Can you go and > see why the Linaro toolchain generated odd "thumb data" at all and get > this fixed? I tried investigating a bit. As I mentioned earlier it doesn't happen with some other files that use the same compiler and linker commands. So, I don't know what's going on. Also, I couldn't reproduce it with a simple program unlike in the other cases. Anyway, I have notified tool-chain folks at Linaro: http://article.gmane.org/gmane.linux.linaro.toolchain/2096 br, Aneesh