From patchwork Mon Nov 26 16:53:39 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Edelsohn X-Patchwork-Id: 201733 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 601D02C0085 for ; Tue, 27 Nov 2012 03:54:05 +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=1354553645; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:In-Reply-To:References:Date: Message-ID:Subject:From:To:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=Nk9EhSJlV7WAfbQdekCckeBUxQk=; b=JpSn586cLCut0tT 4XvvJMuCijZZXuOGEjGnfaXb72M3sFFkPzIOdGm1FgPelxdxwxcsED0jFHgEDLaR uqPTHmvA9YoH3zM8zZ++NEjDE7TlpDApiFwLBU/spub5ClHyrDefRA9txugMtwwC Ez8P41Y3E9bqPyaaAakqC2VIxlgw= 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:In-Reply-To:References:Date:Message-ID:Subject:From:To:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=TzznZZXwekb0edf8eYbE7njm2gIvNLN1Mf4IOsWvGKHzQdDBOw5uMvGOLNaG4B gX08K0u5eOrcrTjsmup+Uc2wF+jXbNluSKzooQAk8QzrvwCj3EWaIYkgYDLjxLlJ 68YZsHBfcJKzBhnijvevRRLTL8nCPzDC1Ttv3cTmeg+XY=; Received: (qmail 22958 invoked by alias); 26 Nov 2012 16:53:47 -0000 Received: (qmail 22864 invoked by uid 22791); 26 Nov 2012 16:53:45 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-vc0-f175.google.com (HELO mail-vc0-f175.google.com) (209.85.220.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Nov 2012 16:53:40 +0000 Received: by mail-vc0-f175.google.com with SMTP id m8so7964130vcd.20 for ; Mon, 26 Nov 2012 08:53:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.220.5 with SMTP id hw5mr19676063vcb.53.1353948819793; Mon, 26 Nov 2012 08:53:39 -0800 (PST) Received: by 10.58.235.232 with HTTP; Mon, 26 Nov 2012 08:53:39 -0800 (PST) In-Reply-To: <87y5hodb2y.fsf@talisman.default> References: <87y5hodb2y.fsf@talisman.default> Date: Mon, 26 Nov 2012 11:53:39 -0500 Message-ID: Subject: Re: [PATCH] Section anchors and thread-local storage From: David Edelsohn To: GCC Patches , rdsandiford@googlemail.com 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 On Mon, Nov 26, 2012 at 3:26 AM, Richard Sandiford wrote: > David Edelsohn writes: >> 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. > > Yeah, TLS anchors "work" on mips64-linux-gnu, although admittedly > section anchors aren't yet enabled by default there, so perhaps not > many people have tried it. I know that it *CAN* work. Part of my question was whether thread-local symbols *SHOULD* be placed in section anchor blocks, whether or not they can be placed there on some systems. > A use_blocks_for_decl_p hook sounds good, and fits nicely with > targetm.use_blocks_for_constant_p. Below is the implementation as a new target hook. Thanks, David * target.def (use_blocks_for_decl_p): New hook. * varasm.c (use_blocks_for_decl_p): Apply hook as final condition. Index: target.def =================================================================== --- target.def (revision 193798) +++ target.def (working copy) @@ -1495,6 +1495,13 @@ bool, (enum machine_mode mode, const_rtx x), hook_bool_mode_const_rtx_false) +/* True if the given decl can be put into an object_block. */ +DEFHOOK +(use_blocks_for_decl_p, + "", + bool, (const_tree decl), + hook_bool_const_tree_true) + /* The minimum and maximum byte offsets for anchored addresses. */ DEFHOOKPOD (min_anchor_offset, Index: varasm.c =================================================================== --- varasm.c (revision 193798) +++ varasm.c (working copy) @@ -1113,7 +1113,7 @@ if (lookup_attribute ("alias", DECL_ATTRIBUTES (decl))) return false; - return true; + return targetm.use_blocks_for_decl_p (decl); } /* Create the DECL_RTL for a VAR_DECL or FUNCTION_DECL. DECL should