sanitizer-coverage vs asan_blacklist

[Timur Iskhodzhanov]

сб, 11 апр. 2015 г. в 20:17, Alexey Samsonov <vonosmas at gmail.com>:

> I think that using blacklist to disable instrumentation because of sandbox
> is a pretty gross hack, and
> the wrong thing to do. I think the better "solution" would be to move
> sandbox-related code to a different
> source files, and compile them with -fno-sanitize=all. Then you can also
> compile them with -fsanitize-coverage=0,
> and the problem would be solved.
>

I don't agree this is a better solution.
Changing the file/code structure of a project to please a deficiency of
every tool we want to use doesn't scale in general.

For example, Chromium's sandbox/ code depends on base/ and we do blacklist
some code from base/.  Some of that code is located in a header file...
I doubt sufficiently changing the file structure would be welcome.
I'm not a GYP expert, so the thought of passing an extra compiler flag for
select TUs scares me as well.


> On Fri, Apr 10, 2015 at 12:16 PM, Timur Iskhodzhanov <timurrrr at google.com>
> wrote:
>
>> (After looking at the code)
>> Is it fine to just return from SanitizerCoverageModule::runOnFunction if
>> a given function doesn't have one of the Sanitize{Address,Thread,Memory}
>> attributes for the "current" sanitizer set?
>>
>
> No. Coverage is also supposed to work with DFSan, and with UBSan (the
> latter doesn't add any attributes to LLVM functions).
>

Alright, can we support that exclusion just for ASan for the time being?


> Logic could be like that:
>> – instrument all the code if we're only doing coverage [w/o
>> asan,msan,tsan]
>> – instrument all the non-blacklisted code, use the same
>> instrument/no-instrument attribute as the "main" sanitizer being used
>>
>> WDYT?
>>
>> пт, 10 апр. 2015 г. в 21:32, Timur Iskhodzhanov <timurrrr at google.com>:
>>
>> ... especially since the blacklist option is called -fsanitize-blacklist.
>>> Just looking at its name, I'd had assumed it affected
>>> -fsanitize-coverage too.
>>>
>>
> I'd try to abstain from using blacklist for coverage instrumentation. If
> we would still definitely have to add it for
> some reason (see above for suggestion regarding sandbox issue in Chrome),
> we can use categories:
>
> src:*/dont/use/coverage.cc=coverage
> fun:DontUseCoverage=coverage
>
>
>>
>>> пт, 10 апр. 2015 г. в 21:08, Timur Iskhodzhanov <timurrrr at google.com>:
>>>
>>> Kostya, Alexey,
>>>>
>>>> I'm currently working on sanitizer coverage on Windows for Chromium.
>>>> As described in http://crbug.com/459166 , we currently blacklist some
>>>> sandbox code from ASan instrumentation, otherwise shadow memory is accessed
>>>> before the RTL is even loaded.
>>>> As it turns out, we should also disable coverage instrumentation for
>>>> that code, otherwise the guard variables are checked before the RTL is
>>>> loaded.
>>>>
>>>> That being said, the ASan blacklist should probably be used in the
>>>> coverage instrumentation module pass.  Or it should have a separate
>>>> blacklist...
>>>>
>>>> What do you think?
>>>> ––
>>>> Timur
>>>>
>>>
>
>
> --
> Alexey Samsonov
> vonosmas at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150411/b8ba6ea9/attachment.html>