[cfe-dev] [ubsan] Check recovery

[Will Dietz]

Many of ubsan's checks are recoverable, and it'd be great to support
doing so when possible.  Example use-case might be trying
-fsanitize=undefined on a new code base that has many errors, where
recovery would allow fixing them in bulk and require fewer
build/test/fix cycles.

This has been discussed a bit previously, and one of the biggest
arguments against this was that making these paths recoverable might
have a negative impact on performance.

To help address this concern, attached are patches that add a
-fsanitize-recover /cc1/ flag to enable performance tests with and
without recovery enabled.  Suggestions on how to proceed with such
testing would be appreciated :).

If performance testing proves the difference is not a concern, the
next step would be making recovery the default and
-fsanitize-no-recover a driver-level flag (with no need for
-fsanitize-recover).  It's certainly important to enable users to
specify they want program execution halted on the first detected error
as is presently the default.

The "recover" phrasing is used (as opposed to "abort" of "trap"
terminology) because many checks cannot be recovered from, so a flag
like -fsanitize-no-abort would be misleading what it does.

Review and feedback on this approach and its direction would be much
appreciated.

Thanks!

~Will
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ubsan-Add-flag-to-enable-recovery-from-checks-when-p.patch
Type: application/octet-stream
Size: 13660 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121130/e068b525/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ubsan-Refactor-handlers-to-never-abort-use-separate-.patch
Type: application/octet-stream
Size: 5630 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121130/e068b525/attachment-0001.obj>