[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