On Tue, Dec 20, 2016 at 12:26:41PM +0100, Martin Liška wrote:
> Ok, llvm folks are unwilling to accept the new API function, thus I've
> decided to come up
> with approach suggested by Jakub. Briefly, when expanding ASAN_POISON
> internal function,
> we create a new variable (with the same name as the original one). The
> variable is poisoned
> at the location of the ASAN_POISON and all usages just call ASAN_CHECK that
> would trigger
> use-after-scope run-time error. Situation where ASAN_POISON has a LHS is very
> rare and
> is very likely to be a bug. Thus suggested not super-optimized approach
> should not be
> problematic.
Do you have a testcase for the case where there is a write to the var after
poison that is then made non-addressable? use-after-scope-9.c only covers
the read.
> I'm not sure about the introduction of 'create_var' function, maybe we would
> need some
> refactoring. Thoughts?
It doesn't belong to gimple-expr.c and the name is way too generic, we have
many create var functions already. And this one is very specialized.
> 2016-12-19 Martin Liska <mli...@suse.cz>
>
> * asan.c (asan_expand_poison_ifn): New function.
> * asan.h (asan_expand_poison_ifn): Likewise.
Too many spaces.
> + tree shadow_var = create_var (TREE_TYPE (poisoned_var),
> + IDENTIFIER_POINTER (DECL_NAME (var_decl)));
For the shadow var creation, IMHO you should
1) use a hash table, once you add a shadow variable for a certain variable
for the first time, reuse it for all the other cases; you can have many
ASAN_POISON () calls for the same underlying variable
2) as I said, use just a function in sanopt.c for this,
create_asan_shadow_var or whatever
3) I think you just want to do copy_node, plus roughly what
copy_decl_for_dup_finish does (and set DECL_ARTIFICIAL and
DECL_IGNORED_P) - except that you don't have copy_body_data
so you can't use it directly (well, you could create copy_body_data
just for that purpose and set src_fn and dst_fn to current_function_decl
and the rest to NULL)
I'd really like to see the storing to poisoned var becoming non-addressable
in action (if it can ever happen, so it isn't just theoretical) to look at
what it does.
Jakub
