This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCHv2] Don't expand string/memory builtins if ASan is enabled.
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Maxim Ostapenko <m dot ostapenko at partner dot samsung dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Yury Gribov <y dot gribov at samsung dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Slava Garbuzov <v dot garbuzov at samsung dot com>, Maxim Ostapenko <chefmax7 at gmail dot com>
- Date: Tue, 11 Nov 2014 15:49:36 -0800
- Subject: Re: [PATCHv2] Don't expand string/memory builtins if ASan is enabled.
- Authentication-results: sourceware.org; auth=none
- References: <5441008A dot 2010706 at partner dot samsung dot com> <54410170 dot 9030100 at partner dot samsung dot com> <20141017122420 dot GR10376 at tucnak dot redhat dot com> <5441132D dot 8000500 at samsung dot com> <20141017130340 dot GW10376 at tucnak dot redhat dot com> <54465EF3 dot 5060601 at partner dot samsung dot com> <5448BBC8 dot 9060807 at samsung dot com> <20141027143458 dot GW10376 at tucnak dot redhat dot com> <544F5205 dot 7090903 at partner dot samsung dot com>
On Tue, Oct 28, 2014 at 1:21 AM, Maxim Ostapenko
<m.ostapenko@partner.samsung.com> wrote:
>
>>> The code which identifies interceptors seems to be duplicated in
>>> expand_builtin. What about factoring this out to some
>>> is_asan_intercepted()
>>> in asan.h?
>>
>> I agree.
>
>
> Fixed this.
>>
>>
>> BTW, when you handle a builtin, but set *intercepted_p to false, is the
>> point just that you don't instrument e.g. scalar accesses to that memory
>> region afterwards? I mean:
>> memcpy (p, "abc", 3);
>> p[0] = 'd';
>> you don't really have to instrument p[0] store, because supposedly memcpy
>> call has already verified p[0] through p[2] is writable.
>>
>> Jakub
>>
>
> Yes, in this case p[0] store is not instrumented we use either intercepted_p
> builtin or not intercepted_p one. But access with some offset e.g. to p[1]
> will be instrumented in both cases. I'll probably fix this next time.
>
> As Yury mentioned, I've also added a test case for pr63638 in this patch.
>
> Tested on x86_64-unknown-inux-gnu.
>
> -Maxim
Your checkin:
https://gcc.gnu.org/ml/gcc-cvs/2014-10/msg01046.html
contains changes to c-c++-common/asan/strlen-overflow-1.c
which isn't listed in ChangeLog.
--
H.J.