From patchwork Tue Nov 19 12:13:42 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ilya Enkovich X-Patchwork-Id: 292369 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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 542ED2C00C8 for ; Tue, 19 Nov 2013 23:14:48 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=BN8hxGx5yPyX1u0As 4LLvKTP3ifzn3ubXJtv65Piz0rKLhefc5/ipSrS3adRi1Cc0oZwUIM6YQ+BIU1GD PWyP3AY4WyhdcHSD1Xidu3n5tiyWJHccpRwcwk7HObprRSDHdOrjcVq4oX4UscMM bZ6fVW0A/XB0eXGb0PzPHcf8BQ= 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:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=JsQSoONie0eGs/auQtovzFO kECY=; b=cGeJZ1rAbzUzZZFvonXiuePxWBBhwR38DlJdRt0w/l9kII9YE2XzWy0 Y3SYZsLbd2u0LtPtxZg6Uc20h2LitbrWtfDvSfZYzLTWtlEQWtlbFSf76R2L0yQw MtWe/5AiAcFEaFa2bJKP71XclK4JxikwDmt+6a1q/kUqvsgxLprk= Received: (qmail 27869 invoked by alias); 19 Nov 2013 12:14:38 -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 27856 invoked by uid 89); 19 Nov 2013 12:14:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.2 required=5.0 tests=AWL, BAYES_50, FREEMAIL_FROM, RDNS_NONE, SPF_PASS, URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail-pa0-f43.google.com Received: from Unknown (HELO mail-pa0-f43.google.com) (209.85.220.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 19 Nov 2013 12:14:36 +0000 Received: by mail-pa0-f43.google.com with SMTP id bj1so155892pad.16 for ; Tue, 19 Nov 2013 04:14:28 -0800 (PST) X-Received: by 10.69.31.97 with SMTP id kl1mr8060131pbd.127.1384863267990; Tue, 19 Nov 2013 04:14:27 -0800 (PST) Received: from msticlxl57.ims.intel.com (fmdmzpr03-ext.fm.intel.com. [192.55.54.38]) by mx.google.com with ESMTPSA id go4sm30162536pbb.15.2013.11.19.04.14.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Nov 2013 04:14:27 -0800 (PST) Date: Tue, 19 Nov 2013 16:13:42 +0400 From: Ilya Enkovich To: Richard Biener Cc: Jeff Law , GCC Patches Subject: Re: [PATCH, MPX, 2/X] Pointers Checker [8/25] Languages support Message-ID: <20131119121342.GR21297@msticlxl57.ims.intel.com> References: <20131108090256.GA21297@msticlxl57.ims.intel.com> <528A4419.7030902@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes On 19 Nov 13:00, Richard Biener wrote: > On Mon, Nov 18, 2013 at 5:45 PM, Jeff Law wrote: > > On 11/08/13 02:02, Ilya Enkovich wrote: > >> > >> Hi, > >> > >> Here is an updated patch version with no langhook. > >> > >> Regarding TLS objects issue - I do not think compiler should compensate > >> the absence of instrumentation in libraries. Compiler should be responsible > >> for initialization of Bounds Tables for .tdata section. Correct data copy > >> is a responsibility of library. User should use either instrumented library > >> or wrapper calls if he needs this functionality. > >> > >> Thanks, > >> Ilya > >> -- > >> gcc/ > >> > >> 2013-11-06 Ilya Enkovich > >> > >> * c/c-parser.c: Include tree-chkp.h. > >> (c_parser_declaration_or_fndef): Register statically > >> initialized decls in Pointer Bounds Checker. > >> * cp/decl.c: Include tree-chkp.h. > >> (cp_finish_decl): Register statically > >> initialized decls in Pointer Bounds Checker. > >> * gimplify.c: Include tree-chkp.h. > >> (gimplify_init_constructor): Register statically > >> initialized decls in Pointer Bounds Checker. > > > > Is parsing really the right time to register these things with the checking > > framework? Doesn't all this stuff flow through the gimplifier? If so > > wouldn't that be a better place? > > > > If it can be done in the gimplifier, which seems good from the standpoint of > > simplifying the long term maintenance of the checking code. > > > > If there's a good reason to have this front-end, please explain it. > > I'd say not in the gimplifier either but in varpool (symbol table) code > where the symbols are ultimatively registered with? Something like that? Thanks, Ilya > > Richard. > > > Thanks, > > Jeff > > --- a/gcc/varpool.c +++ b/gcc/varpool.c @@ -151,6 +151,10 @@ varpool_node_for_decl (tree decl) node = varpool_create_empty_node (); node->decl = decl; symtab_register_node (node); + + if (DECL_NIITIAL (decl)) + chkp_register_var_initializer (decl); + return node; }