From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16664 invoked by alias); 19 Apr 2013 21:38:31 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 16654 invoked by uid 89); 19 Apr 2013 21:38:30 -0000 X-Spam-SWARE-Status: No, score=-5.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 19 Apr 2013 21:38:29 +0000 Received: from localhost.localdomain (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id E098C33BF0D; Fri, 19 Apr 2013 21:38:27 +0000 (UTC) From: Mike Frysinger To: gcc-patches@gcc.gnu.org Cc: nickc@redhat.com, richard.earnshaw@arm.com, paul@codesourcery.com, ramana.radhakrishnan@arm.com Subject: [PATCH] gcc: arm: linux-eabi: fix handling of armv4 bx fixups when linking Date: Sat, 20 Apr 2013 10:59:00 -0000 Message-Id: <1366407647-1956-1-git-send-email-vapier@gentoo.org> X-SW-Source: 2013-04/txt/msg01183.txt.bz2 The bpabi.h header already sets up defines to automatically use the --fix-v4bx flag with the assembler & linker as needed, and creates a default assembly & linker spec which uses those. Unfortunately, the linux-eabi.h header clobbers the LINK_SPEC define and doesn't include the v4bx define when setting up its own. So while the assembler spec is retained and works fine to generate the right relocs, building for armv4 targets doesn't invoke the linker correctly so all the relocs get processed as if we had an armv4t target. You can see this with -dumpspecs when configuring gcc for an armv4 target and using --with-arch=armv4: $ armv4l-unknown-linux-gnueabi-gcc -dumpspecs |& grep -B 1 fix-v4bx *subtarget_extra_asm_spec: .... %{mcpu=arm8|mcpu=arm810|mcpu=strongarm*|march=armv4|mcpu=fa526|mcpu=fa626:--fix-v4bx} ... With this fix in place, we also get the link spec: $ armv4l-unknown-linux-gnueabi-gcc -dumpspecs |& grep -B 1 fix-v4bx *link: ... %{mcpu=arm8|mcpu=arm810|mcpu=strongarm*|march=armv4|mcpu=fa526|mcpu=fa626:--fix-v4bx} ... And all my hello world tests / glibc builds automatically turn the bx insn into the 'mov pc, lr' insn and all is right in the world. Signed-off-by: Mike Frysinger 2013-04-19 Mike Frysinger * config/arm/linux-eabi.h (LINK_SPEC): Add TARGET_FIX_V4BX_SPEC. --- Note: This issue seems to exist since the code was first introduced. At least, I've tested gcc-4.5.x and gcc-4.8.x and they both fail, and the code looks the same in gcc-4.[467].x. That means it's not technically a regression, so I guess policy dictates that it can't be merged into older branches? gcc/config/arm/linux-eabi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h index 4a425c8..8b7ebb2 100644 --- a/gcc/config/arm/linux-eabi.h +++ b/gcc/config/arm/linux-eabi.h @@ -80,7 +80,7 @@ /* At this point, bpabi.h will have clobbered LINK_SPEC. We want to use the GNU/Linux version, not the generic BPABI version. */ #undef LINK_SPEC -#define LINK_SPEC BE8_LINK_SPEC \ +#define LINK_SPEC TARGET_FIX_V4BX_SPEC BE8_LINK_SPEC \ LINUX_OR_ANDROID_LD (LINUX_TARGET_LINK_SPEC, \ LINUX_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC) -- 1.8.2.1