[cfe-dev] more --sanitize= flags

Kostya Serebryany kcc at google.com
Tue Nov 6 13:12:07 PST 2012


On Tue, Nov 6, 2012 at 1:08 PM, Evgeniy Stepanov <eugenis at google.com> wrote:

> This whole -fsanitize= thing looks unorthodox and confusing to me. I
> understand why me might want to merge all sanitizers under one switch, but
> we don't need to put their suboptions there, too.
>
In the suggested syntax, the suboptions that control the behavior of tools
are not using -fsanitize= prefix.
But if we enable an extra functionality in e.g. asan, it could be viewed as
a separate checker that depends on asan, thus
-fsanitize=address,use-after-return makes sense (IMHO).

--kcc



> On Nov 6, 2012 11:58 PM, "Alexander Potapenko" <glider at google.com> wrote:
>
>> -fsanitize=address,use-after-return sounds more like two distinct
>> sanitizers than a sanitizer and an option, although this is very similar to
>> the -Wl case.
>> On Nov 6, 2012 10:53 PM, "Kostya Serebryany" <kcc at google.com> wrote:
>>
>>> Hi,
>>>
>>> We need more clang flags in two categories:
>>>    - flags that modify the behavior of asan/tsan/msan
>>>    - flags that enable additional features of asan/tsan/msan
>>>
>>> As we just discussed with Richard Smith, the flags should probably look
>>> like this:
>>>
>>> modify the behavior:
>>>    -f[no-]sanitize-address-zero-base-shadow # zero base for asan, should
>>> check that -pie is present, linux-only
>>>    -f[no-]sanitize-memory-track-origins  # msan track-origins (once msan
>>> is in trunk, of course)
>>>
>>> add additional features:
>>>   -fsanitize=address,global-init-order,use-after-return,use-after-scope
>>> # asan subphases, currently off by default.
>>>
>>> Does that sound good? Anything else?
>>>
>>> Thanks,
>>>
>>> --kcc
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121106/e21c9df2/attachment.html>


More information about the cfe-dev mailing list