[cfe-dev] [ubsan] Check recovery

[Jordan Rose]

Just a thought: it seems like it'd be useful to enable recovery for some checks but not others. "-fsanitize=undefined -fsanitize-recover=integer"?


On Nov 30, 2012, at 15:58 , Will Dietz <willdtz at gmail.com> wrote:

> 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
> <0001-ubsan-Add-flag-to-enable-recovery-from-checks-when-p.patch><0001-ubsan-Refactor-handlers-to-never-abort-use-separate-.patch>_______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev