This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] ASAN: handle addressable params (PR sanitize/81040).
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Martin Liška <mliska at suse dot cz>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 20 Jun 2017 11:32:04 +0200
- Subject: Re: [PATCH] ASAN: handle addressable params (PR sanitize/81040).
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 4A3D03B74E
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4A3D03B74E
- References: <email@example.com> <20170619141340.GP2123@tucnak> <firstname.lastname@example.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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)
> # .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.