From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83644 invoked by alias); 25 Mar 2015 08:05:20 -0000 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 Received: (qmail 83631 invoked by uid 89); 25 Mar 2015 08:05:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ob0-f170.google.com Received: from mail-ob0-f170.google.com (HELO mail-ob0-f170.google.com) (209.85.214.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 25 Mar 2015 08:05:19 +0000 Received: by obdfc2 with SMTP id fc2so13362880obd.3 for ; Wed, 25 Mar 2015 01:05:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.76.207 with SMTP id z198mr6145273oia.56.1427270717122; Wed, 25 Mar 2015 01:05:17 -0700 (PDT) Received: by 10.202.229.72 with HTTP; Wed, 25 Mar 2015 01:05:17 -0700 (PDT) In-Reply-To: <20150324140619.GE1746@tucnak.redhat.com> References: <20150312100931.GK27860@msticlxl57.ims.intel.com> <20150319082944.GC64546@msticlxl57.ims.intel.com> <20150324083325.GC1746@tucnak.redhat.com> <20150324140619.GE1746@tucnak.redhat.com> Date: Wed, 25 Mar 2015 08:05:00 -0000 Message-ID: Subject: Re: [CHKP, PATCH] Fix instrumented indirect calls with propagated pointers From: Ilya Enkovich To: Jakub Jelinek Cc: gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg01276.txt.bz2 2015-03-24 17:06 GMT+03:00 Jakub Jelinek : > On Tue, Mar 24, 2015 at 12:22:27PM +0300, Ilya Enkovich wrote: >> 2015-03-24 11:33 GMT+03:00 Jakub Jelinek : >> > On Thu, Mar 19, 2015 at 11:29:44AM +0300, Ilya Enkovich wrote: >> >> + /* We might propagate instrumented function pointer into >> >> + not instrumented function and vice versa. In such a >> >> + case we need to either fix function declaration or >> >> + remove bounds from call statement. */ >> >> + if (callee) >> >> + skip_bounds = chkp_redirect_edge (e); >> > >> > I just want to say that I'm not really excited about all this compile time >> > cost that is added everywhere unconditionally for chkp. >> > I think much better would be to guard most of it with proper option check >> > first and only do the more expensive part if the option has been used. >> >> Agree, overhead for not instrumented code should be minimized. >> Unfortunately there is no option check I can use to guard chkp codes >> due to LTO. Currently it is allowed to pass -fcheck-pointer-bounds for >> IL generation and don't pass it for final code generation. I suppose I >> may set this (or some new) flag if see instrumented node when read >> cgraph and then use it to guard chkp related codes. Would it be >> acceptable? > > The question is what you want to do in the LTO case for the different cases, > in particular a TU compiled with -fcheck-pointer-bounds and LTO link without > that, or TU compiled without -fcheck-pointer-bounds and LTO link with it. > It could be handled as LTO incompatible option, where lto1 would error out > if you try to mix -fcheck-pointer-bounds with -fno-check-pointer-bounds > code, or e.g. similar to var-tracking, you could consider adjusting the IL > upon LTO reading if if some TU has been built with -fcheck-pointer-bounds > and the LTO link is -fno-check-pointer-bounds. Dunno what will happen > with -fno-check-pointer-bounds TUs LTO linked with -fcheck-pointer-bounds. > Or another possibility is to or in -fcheck-pointer-bounds from all TUs. Mixing instrumented and not instrumented TUs is allowed. All instrumentation passes happen before LTO link. The only code generation problem if instrumented code is linked with no -fcheck-pointer-bounds is disabled chkp_finish_file call which generates static constructors. I think I just should set flag_check_pointer_bounds if see any instrumented symbol on LTO read. It would cause chkp_finish_file call when required and would be available as guard for chkp related codes. > >> Maybe replace attribute usage with a new flag in tree_decl_with_vis structure? > > Depends, might be better to stick it into cgraph_node instead, depends on > whether you are querying it already early in the FEs or just during GIMPLE > when the cgraph node should be created too. Flag in cgraph_node should work. I'll have a look. Thanks, Ilya > > Jakub