From patchwork Mon Aug 29 16:11:19 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Schmidt X-Patchwork-Id: 112107 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id DB3A9B6F82 for ; Tue, 30 Aug 2011 02:13:30 +1000 (EST) Received: (qmail 11595 invoked by alias); 29 Aug 2011 16:13:25 -0000 Received: (qmail 11583 invoked by uid 22791); 29 Aug 2011 16:13:22 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Aug 2011 16:13:08 +0000 Received: (qmail 15541 invoked from network); 29 Aug 2011 16:13:06 -0000 Received: from unknown (HELO ?84.152.199.150?) (bernds@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 Aug 2011 16:13:06 -0000 Message-ID: <4E5BBA27.4070805@codesourcery.com> Date: Mon, 29 Aug 2011 18:11:19 +0200 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110801 Lightning/1.0b3pre Thunderbird/3.1.11 MIME-Version: 1.0 To: GCC Patches CC: Richard Henderson Subject: Change i386 PIC thunk name Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org We currently generate __i686.get_pc_thunk.bx: movl (%esp), %ebx ret in PIC binaries. This can cause problems if the assembly output ends up in a .S file which is then compiled again: __i686 is a predefined macro and expands to "1". This happens in glibc when compiling csu/crti.S, which is generated from initfini.c; presumably this worked before Richard removed the !TARGET_DEEP_BRANCH_PREDICTION code. A simple way of fixing it would be to change the name of the thunk, as below. Of course, libc also has copies of this code, so worst case we'd end up with two of the thunks, which doesn't seem like a massive problem. Tested on i686-linux (with a few failures which I can attribute to a different patch in the tree). Bernd * config/i386/i386.c (get_pc_thunk_name): Change prefix to "__i686_get_pc_thunk.". Index: config/i386/i386.c =================================================================== --- config/i386/i386.c (revision 178030) +++ config/i386/i386.c (working copy) @@ -8339,7 +8339,7 @@ get_pc_thunk_name (char name[32], unsign gcc_assert (!TARGET_64BIT); if (USE_HIDDEN_LINKONCE) - sprintf (name, "__i686.get_pc_thunk.%s", reg_names[regno]); + sprintf (name, "__i686_get_pc_thunk.%s", reg_names[regno]); else ASM_GENERATE_INTERNAL_LABEL (name, "LPR", regno); }