From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61882 invoked by alias); 25 Mar 2015 08:50:10 -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 61872 invoked by uid 89); 25 Mar 2015 08:50:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.9 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-oi0-f45.google.com Received: from mail-oi0-f45.google.com (HELO mail-oi0-f45.google.com) (209.85.218.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 25 Mar 2015 08:50:07 +0000 Received: by oier21 with SMTP id r21so15728428oie.1 for ; Wed, 25 Mar 2015 01:50:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.68.20 with SMTP id r20mr6527026oet.26.1427273405243; Wed, 25 Mar 2015 01:50:05 -0700 (PDT) Received: by 10.202.229.72 with HTTP; Wed, 25 Mar 2015 01:50:05 -0700 (PDT) In-Reply-To: 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:50:00 -0000 Message-ID: Subject: Re: [CHKP, PATCH] Fix instrumented indirect calls with propagated pointers From: Ilya Enkovich To: Richard Biener Cc: Jakub Jelinek , gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg01280.txt.bz2 2015-03-24 17:40 GMT+03:00 Richard Biener : > On Tue, Mar 24, 2015 at 3:06 PM, Jakub Jelinek wrote: >> On Tue, Mar 24, 2015 at 12:22:27PM +0300, Ilya Enkovich wrote: >> >> 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. >> >>> 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. > > I also wonder why it is necessary to execute pass_chkp_instrumentation_passes > when mpx is not active. > > That is, can we guard that properly in > > void > pass_manager::execute_early_local_passes () > { > execute_pass_list (cfun, pass_build_ssa_passes_1->sub); > execute_pass_list (cfun, pass_chkp_instrumentation_passes_1->sub); > execute_pass_list (cfun, pass_local_optimization_passes_1->sub); > } I'm worried about new functions generated in LTO. But with re-created flag_check_pointer_bounds it should be safe to guard it. > > (why's that so oddly wrapped?) > > class pass_chkp_instrumentation_passes > > also has no gate that guards with flag_mpx or so. > > That would save a IL walk over all functions (fixup_cfg) and a cgraph > edge rebuild. Right. Will fix it. Thanks, Ilya > > Richard. > >> Jakub