From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28972 invoked by alias); 16 Jan 2013 09:29:56 -0000 Received: (qmail 28963 invoked by uid 22791); 16 Jan 2013 09:29:55 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Jan 2013 09:29:51 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0G9ToE5002921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Jan 2013 04:29:50 -0500 Received: from freie.oliva.athome.lsd.ic.unicamp.br (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r0G9TlIh017396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jan 2013 04:29:49 -0500 Received: from livre.localdomain (livre-to-gw.oliva.athome.lsd.ic.unicamp.br [172.31.160.19]) by freie.oliva.athome.lsd.ic.unicamp.br (8.14.5/8.14.5) with ESMTP id r0G9TcCc019960; Wed, 16 Jan 2013 07:29:38 -0200 Received: from livre.localdomain (aoliva@localhost.localdomain [127.0.0.1]) by livre.localdomain (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r0G9Tbix008028; Wed, 16 Jan 2013 07:29:38 -0200 Received: (from aoliva@localhost) by livre.localdomain (8.14.3/8.14.3/Submit) id r0G9TaOr008026; Wed, 16 Jan 2013 07:29:36 -0200 From: Alexandre Oliva To: Richard Biener Cc: gcc-patches@gcc.gnu.org, Jan Hubicka Subject: Re: [PR libmudflap/53359] don't register symbols not emitted References: Date: Wed, 16 Jan 2013 09:29:00 -0000 In-Reply-To: (Richard Biener's message of "Mon, 7 Jan 2013 10:27:54 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 X-SW-Source: 2013-01/txt/msg00830.txt.bz2 On Jan 7, 2013, Richard Biener wrote: > On Sun, Jan 6, 2013 at 8:47 PM, Alexandre Oliva wrote: >> On Jan 2, 2013, Richard Biener wrote: >> >>> On Sun, Dec 30, 2012 at 1:22 AM, Alexandre Oliva wrote: >>>> On Dec 21, 2012, Richard Biener wrote: >>>> >>>>> On Fri, Dec 21, 2012 at 6:33 AM, Alexandre Oliva wrote: >>>>>> libmudflap emits a global initializer that registers memory ranges for >>>>>> global data symbols. However, even if IPA decides not to emit a symbol >>>>>> because it's unused, we'd still emit registration sequences for them in >>>>>> some cases, which, in the PR testcase, would result in TOC references to >>>>>> the undefined symbols. >>>> >>>>> Hmm, I think that at this point of the compilation you are looking for >>>>> TREE_ASM_WRITTEN instead. >>>> >>>> That doesn't work, several mudflap regressions show up because accesses >>>> to global library symbols that are accessed by template methods compiled >>>> with mudflap (say cout) are then verified but not registered. We have >>>> to register symbols that are not emitted but that referenced. >> >>> Ehm, how can something be not emitted but still referenced? You mean if >>> it's external? >> >> Yeah. >> >>> if (!TREE_ASM_WRITTEN (obj) || DECL_EXTERNAL (obj)) >> >>> instead? >> >> Then we're back to the original bug. >> >> How does the test above tell whether we're actually referencing the >> object? Only when we are do we want to register it with mudflap. If >> it's referenced and we don't register it, we get mudflap runtime errors. >> If it's not referenced but we register it, we get link-time errors if >> the symbol is one we'd have emitted if it was referenced. > Then the bug is that we register something but do not actually tell the > middle-end that this is a reference. No, the bug is that we're registering something because at an earlier point (when we emitted checks) there were references to it. The references were all optimized away, we correctly decided (elsewhere) the object was not referenced, and we removed it from the symbol table, but mudflap still wants to register it because it pays no attention to that decision. This is the reason why I believe the patch I proposed initially is the correct fix. Now, can you please tell me why you believe this diagnosis is incorrect, or why the fix for the diagnosed problem is incorrect, to the point of proposing alternate (faulty) approaches? > I suppose instead of asking for TREE_ASM_WRITTEN you may want to look > at DECL_RTL (which should be set for all referenced decls, whether > external or not). I'm pretty sure the optimized-away objects that we do NOT want to register had DECL_RTL set, but I'm not exactly excited about double checking it without at least a hint of an explanation on what seems to be wrong with the proposed patch. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer