From patchwork Sun Nov 25 19:02:05 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Edelsohn X-Patchwork-Id: 201561 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 71D7C2C0086 for ; Mon, 26 Nov 2012 06:02:16 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1354474937; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:Date:Message-ID:Subject:From:To: Cc:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=pA7C3/T ontbaZSVNHkRMviPDcM4=; b=gIo6JVW+d0N8gMpc+r8VGxNAAiVWNqch6QyJoww MsmN7+a3hD7tSoN0Bu7LYcUotlcNY1BgeIscLkNiIqZ4Gj+znIFRRhohJBo2s65Y Qf++hwlpAifI4N2EuGuuDbxJztNOs8LNYcNkv3KTWOFtAOPNoY5lRhzdA9doi/k4 lnkY= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:MIME-Version:Received:Received:Date:Message-ID:Subject:From:To:Cc:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=kbyt3pqx4Y1Ff8t1EFm2kNgbKR53Hd5At608x/Ll58/Zdg77EBP9DiEFoUvE1H xu1p70b3WejQRVlp+WLaklUp3nydfu4kHDJRSk7v4/twPLAEjbBf/dciv/+2sTry 7Nsa7WLgFSa/qG5yEut5ymQZMofRC57x6cycCFwYjAGy4=; Received: (qmail 22921 invoked by alias); 25 Nov 2012 19:02:13 -0000 Received: (qmail 22913 invoked by uid 22791); 25 Nov 2012 19:02:13 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL, BAYES_05, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-vb0-f47.google.com (HELO mail-vb0-f47.google.com) (209.85.212.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 25 Nov 2012 19:02:06 +0000 Received: by mail-vb0-f47.google.com with SMTP id e21so8560693vbm.20 for ; Sun, 25 Nov 2012 11:02:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.148.134 with SMTP id p6mr15541691vcv.3.1353870126000; Sun, 25 Nov 2012 11:02:06 -0800 (PST) Received: by 10.58.235.232 with HTTP; Sun, 25 Nov 2012 11:02:05 -0800 (PST) Date: Sun, 25 Nov 2012 14:02:05 -0500 Message-ID: Subject: [PATCH] Section anchors and thread-local storage From: David Edelsohn To: Richard Sandiford Cc: GCC Patches 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 I have been working to enable native thread-local storage on AIX. One problem I encountered is the AIX assembler has difficulty with the anchor symbol for TLS CSECTs. While the section anchors machinery uses a separate pool for TLS entries, should section anchor blocks be used for TLS symbols at all? powerpc-linux uses GOT annotations directly and never places TLS symbols in the TOC at all. Section anchors seem to be avoided by TLS code already. The appended patch rejects TLS symbols for object blocks in general. I could add a target hook, but I wanted to propose this policy in general before pursing a target-specific hook. Thanks, David * varasm.c: (use_blocks_for_decl_p): Do not place thread-local symbols refs in object blocks. Index: varasm.c =================================================================== --- varasm.c (revision 193785) +++ varasm.c (working copy) @@ -1108,6 +1108,10 @@ if (DECL_INITIAL (decl) == decl) return false; + /* Do not place thread-local symbols refs in the object blocks. */ + if (DECL_TLS_MODEL (decl) != 0) + return false; + /* If this decl is an alias, then we don't want to emit a definition. */ if (lookup_attribute ("alias", DECL_ATTRIBUTES (decl)))