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
It seems weird to me, as a user, than the syntax to modify behavior would not reuse the “-fsanitize” common prefix.
There is precedent in -Wl being able to forward parameters to the linker already, so maybe a dedicated “-fsanitize-flags=address,…” could just forward the flags (whatever they are) to ASan and let it parse them. If the commas pose an issue, then perhaps than a “-fsanitize-address flag” would be simpler, with the latter part (address) being taken from the list of known checkers.
– Matthieu
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
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
It seems weird to me, as a user, than the syntax to modify behavior would
not reuse the "-fsanitize" common prefix.
The idea is that -fsanitize=... specifies which things to check for.
These -fsanitize-... arguments instead specify details of how the
checks should behave (at the implementation level) and how they should
report issues. It would seem weird to me as a user to use
-fsanitize=... to control the implementation of a check, rather than
to enable a check. This is intended to parallel the warning flags,
where -W... controls which warnings are displayed, and
-fdiagnostics-... control how the diagnostics system itself behaves.
There is precedent in -Wl being able to forward parameters to the linker
already, so maybe a dedicated "-fsanitize-flags=address,....." could just
forward the flags (whatever they are) to ASan and let it parse them. If the
This situation is not like -Wl. We're not calling some external tool
with a potentially-unknown command-line interface. These arguments are
interpreted by Clang itself.
commas pose an issue, then perhaps than a "-fsanitize-address flag" would be
simpler, with the latter part (address) being taken from the list of known
checkers.
That is the proposed syntax, except that we use a dash instead of a space.
-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.
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.
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
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).
I agree with that.
One more random thought - ASan supports blacklist file (-mllvm -asan-blacklist). Do we want to pull this flag into Clang as well?
Can the family of undefined-behavior sanitizers make use of it? It looks like I’ve forgotten the reason why this file is used
at LLVM level, not in Clang. IIUC in Clang we can just avoid emitting address_safety attribute for functions/globals in the blacklist file.
It can be more convenient for per-function blacklisting (instead of per-file) because we probably can pattern-match names that are not
yet mangled (can’t we?)