This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Asan constructor init order checking
- From: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Alexey Samsonov <samsonov at google dot com>, Dodji Seketeli <dseketel at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 15 Nov 2013 22:55:07 +0400
- Subject: Re: [PATCH] Asan constructor init order checking
- Authentication-results: sourceware.org; auth=none
- References: <20131115135845 dot GE892 at tucnak dot redhat dot com> <CAGQ9bdye6=pkW9N-VHrNpTigH9zKjYduqVFb4_Q1RTkH=Uy9RQ at mail dot gmail dot com> <20131115184652 dot GP892 at tucnak dot redhat dot com>
On Fri, Nov 15, 2013 at 10:46 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Nov 15, 2013 at 10:34:28PM +0400, Konstantin Serebryany wrote:
>> +samsonov, who wrote the clang part
>>
>> Do you plan to add tests?
>
> OT, what is the -fsanitize=address,use-after-scope doing? Tried that
> and it didn't seem to do anything at all, besides adding some extra
> start/end scope markers to the IL, but not actually adding any
> instrumentation. Is that just not done yet? What are you planning for
Yes, this one is not ready yet. It handles only the simplest cases and
is actually unstable yet.
The largest piece of work is in the compiler: make the frontend and
inliner emit these CLOBBER
statements and teach other optimizations not to mess around with them.
The run-time support is more or less straightforward, although it has
to be tuned for performance.
> that? For a subset of vars poison them upon entry to the function and
> then when entering their scope unpoison them and when leaving scope poison
> them again?
right.
> GCC right now has just var ={v} {CLOBBER}; statements that
> mark vars going out of scope, we could add for asan only add also into scope
> markers, make sure they are never optimized away (current CLOBBERs are just
> optimization hints and in some cases it is better to optimize them away
> rather than e.g. get worse EH code), but because they are used for
> optimizations, programs with use-after-scope bugs often get miscompiled by
> GCC (well, they have undefined behavior, so miscompiled is a weird term),
> it would be nice to have asan complain about those.
We've been bitten by these "legal miscompiles" quite a few times.
that's exactly why we started doing this thing. Just haven't finished yet.
>
> Jakub