From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Thu, 09 Feb 2012 14:28:21 +0530 Subject: [U-Boot] [RFC PATCH 2/4] OMAP3+: fix issues with Thumb build In-Reply-To: <4F3040D0.5070808@aribaud.net> References: <1328528248-20872-1-git-send-email-aneesh@ti.com> <1328528248-20872-3-git-send-email-aneesh@ti.com> <4F3040D0.5070808@aribaud.net> Message-ID: <4F338AAD.8070905@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 Hi Albert, On Tuesday 07 February 2012 02:36 AM, Albert ARIBAUD wrote: > Le 06/02/2012 12:37, Aneesh V a ?crit : >> When U-Boot/SPL is built using the Thumb instruction set the >> toolchain has a potential issue with weakly linked symbols. >> If a function has a weakly linked default implementation in C >> and a real implementation in assembly GCC is confused about the >> instruction set of the assembly implementation. As a result >> the assembly function that is built in ARM is executed as >> if it is Thumb. This results in a crash. >> >> We need to investigate further to see if this is a toolchain >> issue or an issue with our usage of it. In the meanwhile, we >> can workaround the issue by having both the weakly linked alias >> and the real implementation in C. > > I would tend to NAK a patch submission where an issue is known and > investigation is considered but is actually bypassed by a workaround. > These tend to turn from 'temporary fix' to 'old crust' with time, > because there is no incentive for a better solution when the quick fix > "works, after all". I have a solution to this problem now. The following change solves it. diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S index 35f38ac..177af7a 100644 --- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S +++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S @@ -28,6 +28,7 @@ #include +.type save_boot_params, %function .global save_boot_params save_boot_params: /* Apparently having the symbol marked as %function type in the symbol table helps ld. However, not having the %function tag doesn't prevent ld from linking correctly to this function. It affects only ARM/Thumb resolution. Strange! I came to this solution from the test-code provided by Ulrich Weigand in reply to my queries in Linaro ML [1]. I couldn't reproduce the problem with his code, but eventually could break it when I removed the %function. I will continue this discussion there and to understand whether this is a limitation with GCC. However, hope you are fine with the above solution. I shall fix up all assembly functions in arm. [1] http://article.gmane.org/gmane.linux.linaro.devel/3073 br, Aneesh