[PATCHv2] Don't expand string/memory builtins if ASan is enabled.
Maxim Ostapenko
m.ostapenko@partner.samsung.com
Tue Oct 21 13:38:00 GMT 2014
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 update
asan_mem_ref_ht with (base, size_in_bytes), if we can determine access
size during compile time.
3) Removed ASAN_CHECK_START_INSTRUMENTED and ASAN_CHECK_END_INSTRUMENTED
from asan_check_flags since we don't instrument base and end of
memory region with access size 1 anymore.
4) Specified builtins that shouldn't be expanded explicitly in
gcc/builtins.c.
Regtested / bootrapped on x86_64-unknown-linux-gnu.
-Maxim
On 10/17/2014 05:03 PM, Jakub Jelinek wrote:
> On Fri, Oct 17, 2014 at 05:01:33PM +0400, Yury Gribov wrote:
>> On 10/17/2014 04:24 PM, Jakub Jelinek wrote:
>>>> +/* Returns TRUE if given FCODE corresponds to string or memory builtin function.
>>>> + */
>>>> +
>>>> +static inline bool
>>>> +is_memory_builtin (enum built_in_function fcode)
>>>> +{
>>>> + return fcode <= BUILT_IN_STRSTR && fcode >= BUILT_IN_BCMP;
>>> This is too fragile and ugly.
>>> IMHO you should list (supposedly not in a special inline, but directly
>>> where you use it) in a switch all the builtins you don't want to expand.
>> We already do this for BUILT_IN_ASAN_REPORT_LOAD1 ... BUILT_IN_ASAN_STOREN
> I know, but it is still a coherent sent of builtins for very similar
> purposes, many of them sorted by increasing size number.
>
>> but I agree that this one is more ugly.
> The memops builtins are just random bag of them, it is expected many people
> will add builtins into that range and outside of that range.
>
> Jakub
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: builtins-17.diff
Type: text/x-patch
Size: 35202 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20141021/3a265aa1/attachment.bin>
More information about the Gcc-patches
mailing list