From patchwork Thu May 16 14:32:56 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rainer Orth X-Patchwork-Id: 244345 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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 62F882C009D for ; Fri, 17 May 2013 00:33:10 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; q=dns; s=default; b=cjWVdeiABSj+Ej+s uVeN0Uf+EKYX6s2695UI8moGr502JdFWNoSwg0pW0VX7kk8YcgXGvpd0qokzo+QI FicZC+MXU6l6Ym0MNhSYVb7hgrw/DMMyX2z1U2osdeGFHGbkPxwi4ihA2dMzX+sg qE3u3tK3yc0hS0Tg7cHJANYJAH4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; s=default; bh=qUXex3Ib2Q8PDQH1Ui5kLs 1qjdw=; b=g7EaZ5IAuFN2vlrcY2pcaDpZErAJp5WhlO9dXxeS58lD71F+i+vx1A Pu3Lou2+C6ApkHjBInokMHhvzuTCiz+urS22QfjzU0cf4HKLugSyVBDvIv9m/y6Y jPsC/LxmcfEH6POS8o9ylj/8vHtE5y7zAs/m8qOYM7/gVqNqHCC/k= Received: (qmail 6953 invoked by alias); 16 May 2013 14:33:04 -0000 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 Received: (qmail 6927 invoked by uid 89); 16 May 2013 14:33:04 -0000 X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from snape.CeBiTec.Uni-Bielefeld.DE (HELO smtp-relay.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 16 May 2013 14:33:02 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id D3F3A212; Thu, 16 May 2013 16:32:59 +0200 (CEST) Received: from smtp-relay.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hh5UZTi-aNf2; Thu, 16 May 2013 16:32:57 +0200 (CEST) Received: from lokon.CeBiTec.Uni-Bielefeld.DE (lokon.CeBiTec.Uni-Bielefeld.DE [129.70.161.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-relay.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id 2D9FB210; Thu, 16 May 2013 16:32:57 +0200 (CEST) Received: (from ro@localhost) by lokon.CeBiTec.Uni-Bielefeld.DE (8.14.5+Sun/8.14.5/Submit) id r4GEWu6P006090; Thu, 16 May 2013 16:32:56 +0200 (MEST) From: Rainer Orth To: Nathan Sidwell Cc: GCC Patches Subject: Re: section anchors and weak hidden symbols References: <518A3D8E.5020800@acm.org> Date: Thu, 16 May 2013 16:32:56 +0200 In-Reply-To: <518A3D8E.5020800@acm.org> (Nathan Sidwell's message of "Wed, 08 May 2013 12:57:02 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 X-Virus-Found: No Nathan Sidwell writes: > This patch fixes a problem with section anchors. Found on powerpc, but > also appears on MIPS and ARM targets. > > Section anchors can only be used for definitions known to bind in the > current object file. The default predicate uses the bind_local_p hook to > determine this. Unfortunately that hook determines whether the decl's > binding is determined at static link time (i.e. within the dynamic object > this object is linked). That's very nearly the same, except for symbols > that have a weak hidden definition in this object file. For such symbols, > binds_local_p returns true, because the binding must be within the dynamic > object. But we shouldn't use a section anchor as a definition in a > different object file could win at static link time. (I'm not 100% sure > there aren't other cases where module-binding and object-binding differ for > a definition.) > > It surprised me that binds_local_p has the semantics it does -- perhaps its > meaning has changed, or it is simply poorly named. I would have thought > binds_module_p would be a better name. > > Anyway, rather than go on a renaming exercise, I chose to adjust > default_use_anchors_for_symbol_p to reject any weak symbol. > > tested on powerpc-linux-gnu, ok? The new gcc.dg/visibility-21.c testcase fails on i386-pc-solaris2.11 and x86_64-unknown-linux-gnu: FAIL: gcc.dg/visibility-21.c (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/visibility-21.c:1:0: warning: this target does not support '-fsection-anchors' [-fsection-anchors] Fixed as follows, tested with the appropriate runtest invokation on both targets where the test becomes UNSUPPORTED, installed on mainline. Rainer 2013-05-16 Rainer Orth * gcc.dg/visibility-21.c: Require section_anchors. # HG changeset patch # Parent e3635f5f20529d75a74064c8282ce002932dde78 Require section_anchors in gcc.dg/visibility-21.c diff --git a/gcc/testsuite/gcc.dg/visibility-21.c b/gcc/testsuite/gcc.dg/visibility-21.c --- a/gcc/testsuite/gcc.dg/visibility-21.c +++ b/gcc/testsuite/gcc.dg/visibility-21.c @@ -3,6 +3,7 @@ /* { dg-options "-O2 -fsection-anchors" } */ /* { dg-require-visibility "" } */ /* { dg-require-weak "" } */ +/* { dg-require-effective-target section_anchors } */ /* { dg-final { scan-assembler-not "ANCHOR" } } */ int __attribute__((weak, visibility("hidden"))) weak_hidden[3];