From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41318 invoked by alias); 28 Jun 2017 13:16:12 -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 41301 invoked by uid 89); 28 Jun 2017 13:16:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=36AM, 36am, HContent-Transfer-Encoding:8bit X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Jun 2017 13:16:10 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 110A3AAB6; Wed, 28 Jun 2017 13:16:08 +0000 (UTC) Subject: Re: [PATCH] ASAN: handle addressable params (PR sanitize/81040). From: =?UTF-8?Q?Martin_Li=c5=a1ka?= To: Jakub Jelinek Cc: GCC Patches References: <20170619141340.GP2123@tucnak> <20170620093204.GF2123@tucnak> Message-ID: <076702bb-38e0-6ff4-8934-363fdc781390@suse.cz> Date: Wed, 28 Jun 2017 13:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg02159.txt.bz2 PING^1 On 06/20/2017 03:06 PM, Martin Liška wrote: > On 06/20/2017 11:32 AM, Jakub Jelinek wrote: >> On Tue, Jun 20, 2017 at 11:23:36AM +0200, Martin Liška wrote: >>>> Then something needs to be done for debugging too. If it is without VTA, >>>> then probably just having DECL_VALUE_EXPR is good enough, otherwise >>>> (VTA) you probably don't want that (or can reset it at that point), but >>>> instead emit after the initialization stmt a debug stmt that the variable >>>> value now lives in a different var. Though ideally we want the debugger >>>> to be able to also change the value of the var, that might be harder. >>>> With DECL_VALUE_EXPR on the other side the debug info will be incorrect in >>>> the prologue until it is assigned to the slot. >>> >>> Here I'm not sure about how to distinguish whether to build or not to build >>> the debug statement. According to flag_var_tracking? >> >> More like if (target_for_debug_bind (arg)) >> And if that is false, just make sure DECL_VALUE_EXPR is set to var. >> >>> You mean something like: >>> g = gimple_build_debug_bind (arg, var, g); >>> ? >> >> Well, there is no stmt, so the last argument would be just NULL. >> >>>> I don't understand the distinction. If you turn the original parm >>>> for complex/vector DECL_GIMPLE_REG_P, you should need the exact same code >>>> (but I think it would be better to use the default SSA_NAME of the PARM_DECL >>>> if it is a gimple reg type, rather than use the PARM_DECL itself >>>> and wait for update_ssa). >>> >>> Yes, the test-case /gcc/testsuite/g++.dg/asan/function-argument-3.C fails for me >>> as one needs to have a temporary SSA name, otherwise: >>> >>> /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/asan/function-argument-3.C:13:1: error: invalid rhs for gimple memory store >>> foo (v4si arg) >>> ^~~ >>> arg >>> >>> arg >>> >>> # .MEM_4 = VDEF <.MEM_1(D)> >>> arg = arg; >>> during GIMPLE pass: sanopt >>> >>> If I see correctly the function in my test-case does not have default def SSA name for the parameter. >>> Thus I guess I need to create a SSA name? >> >> I'd expect if you have DECL_GIMPLE_REG_P set on the PARM_DECL and >> use the default def, you shouldn't run into this. >> >> Jakub >> > > Good I fixed that in v2, that passes regression tests. > Ale objections should be resolved in the version. > > Ready for trunk? > Martin >