On Tue, Oct 28, 2014 at 1:21 AM, Maxim Ostapenko
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 built
On Tue, Oct 28, 2014 at 12:21:25PM +0400, Maxim Ostapenko wrote:
> 2014-10-28 Max Ostapenko
>
> * asan.h (is_asan_intercepted): New function.
I'd call it asan_intercepted_p instead.
Can you please check if:
void foo (char *p)
{
volatile int zero = 0;
memcpy (p, "abc", zero);
p[0]
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. sc
On Thu, Oct 23, 2014 at 12:26:48PM +0400, Yury Gribov wrote:
> On 10/21/2014 05:26 PM, Maxim Ostapenko wrote:
> >Hi,
> >
> >this is the second version of the patch. Here the major changes from the
> >previous one:
>
> [snip]
>
> > case BUILT_IN_BCMP:
> >+ *intercepted_p = false;
>
> Th
On 10/21/2014 05:26 PM, Maxim Ostapenko wrote:
Hi,
this is the second version of the patch. Here the major changes from the
previous one:
[snip]
case BUILT_IN_BCMP:
+ *intercepted_p = false;
The code which identifies interceptors seems to be duplicated in
expand_builtin. What
Hi,
this is the second version of the patch. Here the major changes from the
previous one:
1) Added a new intercepted_p parameter in get_mem_refs_of_builtin_call
to decide whether builtin function should/shouldn't be instrumented.
2) Changed instrument_mem_region_access function. Now, we up
