sanitizer-coverage vs asan_blacklist

[Timur Iskhodzhanov]

(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?

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.
>
> пт, 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150410/41d0995a/attachment.html>