This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Martin Liška <mliska at suse dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 2 Nov 2016 13:36:31 +0100
- Subject: Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)
- Authentication-results: sourceware.org; auth=none
- References: <20160818133609.GN14857@tucnak.redhat.com> <98f408c5-7e1e-6fd8-e589-34f8de2f4455@suse.cz> <20161007111347.GF7282@tucnak.redhat.com> <bcad9f73-a54c-bc50-2bcc-a6f0f8c9e9c4@suse.cz> <20161021142617.GG7282@tucnak.redhat.com> <3a109250-0440-7438-8e1f-7e5c6d8b6580@suse.cz> <20161027172358.GN3541@tucnak.redhat.com> <606cd948-6cba-02a4-f114-35900ab53203@suse.cz> <20161101151219.GT3541@tucnak.redhat.com> <CAFiYyc3bLw=mkwWj_5sbr07nznG3_1-Sf5PObLQdhg9-tvNVVA@mail.gmail.com> <20161102095202.GL3541@tucnak.redhat.com>
On Wed, Nov 2, 2016 at 10:52 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Nov 02, 2016 at 10:40:35AM +0100, Richard Biener wrote:
>> > I wonder if the sanitize_asan_mark wouldn't better be some PROP_* property
>> > set during the asan pass and kept on until end of compilation of that
>> > function. That means even if a var only addressable because of ASAN_MARK is
>> > discovered after this pass we'd still be able to rewrite it into SSA.
>>
>> Note that being TREE_ADDRESSABLE also has effects on alias analysis
>> (didn't follow the patches to see whether you handle ASAN_MARK specially
>> in points-to analysis and/or alias analysis).
>>
>> Generally in update-address-taken you can handle ASAN_MARK similar to
>> MEM_REF (and drop it in the rewrite phase?).
>
> That is the intent, but we can't do that before the asan pass, because
> otherwise as Martin explained we don't diagnose at runtime bugs where
> a variable is used outside of its scope only through a MEM_REF.
> So we need to wait for asan pass to actually add a real builtin call that
> takes the address in that case. Except now I really don't see how that
> can work for the case where the var is used only properly when it is in the
> scope, because the asan pass will still see those being addressable.
>
> Unless I'm missing something we either need to perform further analysis
> during the addressable subpass - this variable could be made
> non-addressable, but is used in ASAN_MARK, would if we rewrote it into SSA
> form there be any SSA uses of the poisoning ASAN_MARK? If yes, keep it
> addressable, otherwise rewrite into SSA.
> Or, just rewrite it into SSA always, but turn the poisoning ASAN_MARK into
> some new internal ECF_CONST call var_5 = ASAN_POISON (); and if we have any
> uses of those, rewrite it back into addressable immediately or later or
> something.
Or just give up optimizing (asan has a penalty anyway)? Or
re-structure ASAN_POISON ()
similar to clobbers:
var = ASAN_POISION ();
that avoids the address-taking and thus should be less heavy-weight on
optimizations.
Richard.
>
> Jakub