This is an archive of the discontinued LLVM Phabricator instance.

Reimplement -fsanitize-recover family of flags.
ClosedPublic

Authored by samsonov on Nov 17 2014, 6:13 PM.

Details

Reviewers
kcc
rsmith
Summary

Introduce the following -fsanitize-recover flags:

  • -fsanitize-recover: Enable recovery for all checks enabled by -fsanitize= which support it.
  • -fno-sanitize-recover: Disable recovery for all checks.
  • -fsanitize-recover=<list>: Enable recovery for all selected checks or group of checks. It is forbidden to list unrecoverable sanitizers here (that is, "address", "unreachable", "return").
  • -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks.

These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly,
much like what we do for -fsanitize= flags.
-fsanitize= and -fsanitize-recover= flag families are independent.

CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple
checks, which have different recoverable setting, then we emit two handler calls instead of one:
the first one for the set of "unrecoverable" checks, another one - for set of "recoverable"
checks. If all checks implemented by a handler have the same recoverability setting, then the
generated code will be the same.

Diff Detail

Event Timeline

samsonov updated this revision to Diff 16313.Nov 17 2014, 6:13 PM
samsonov retitled this revision from to Reimplement -fsanitize-recover family of flags..
samsonov updated this object.
samsonov edited the test plan for this revision. (Show Details)
samsonov added a reviewer: rsmith.
samsonov added a subscriber: Unknown Object (MLST).
samsonov updated this revision to Diff 17613.Dec 23 2014, 4:42 PM

Rebase the changes against trunk. Add tests for -fsanitize-recover=all
and -fno-sanitize-recover=all shorthands. Turned -f(no-)?sanitize-recover
into synonyms of -f(no-)?sanitize-recover=undefined,integer to keep
the current flag semantics and behave the same as GCC.

Please review.

Richard, could you please take a look at this? -fsanitize-recover= variant is already in GCC trunk, and I hoped we could have these flags in soon-to-be-branched Clang 3.6...

rsmith accepted this revision.Jan 9 2015, 5:50 PM
rsmith edited edge metadata.

A few comments, go ahead once these are handled.

include/clang/Driver/Options.td
537–541

Maybe remove the HelpText and leave this undocumented now that it's deprecated.

lib/CodeGen/CGExpr.cpp
2308

Typo RecoverableCond?

I don't think it's obvious what we should do if the user turns on both -fsanitize-recover=something and also -fsanitize-undefined-trap-on-error. Since the latter is usually used in cases where the sanitizer runtime is not available (when building an OS kernel or the like), I think it should overrule -fsanitize-recover (as it does), and the answer to your FIXME is "no, we shouldn't".

2363

Passing NonFatalHandlerBB here seems strange: there should be no control flow path out of the fatal error handler; we should call the _abort runtime function, which doesn't return.

lib/Frontend/CompilerInvocation.cpp
335

You should probably check for unrecoverable sanitizers for the -fsanitize-recover= case here, too, in case someone passes a bad argument to -cc1 directly.

This revision is now accepted and ready to land.Jan 9 2015, 5:50 PM

Thank you! Addressed most of the comments and added docs about the new flag. Submitting.

include/clang/Driver/Options.td
537–541

Done

lib/CodeGen/CGExpr.cpp
2308

Right. Replaced the FIXME with comment describing that -fsanitize-undefined-trap-on-error overrides -fsanitize-recover= options.

2363

No, there is CheckRecoverableKind::AlwaysRecoverable (vptr sanitizer), so we may return even from __ubsan_handle_dynamic_type_cache_miss_abort.

lib/Frontend/CompilerInvocation.cpp
335

Right. It's hard to fix it immediately, as we only support SANITIER_GROUP handling in driver. I've added a FIXME and will address this later.

samsonov closed this revision.Jan 12 2015, 2:52 PM