[cfe-dev] [ubsan] Check recovery

[Alexey Samsonov]

I'll leave all the ubsan-relevant part to Richard. Just a general comment:
I think you'd need driver support for these flags (especially if you follow
Jordan's idea).
Your flags targets -fsanitize=undefined, but it wouldn't make any sense for
e.g. -fsanitize=address
(as it cannot recover from errors by design).

On Fri, Nov 30, 2012 at 4:28 PM, Will Dietz <willdtz at gmail.com> wrote:

> Forgive me, the previous patches erroneously aborted on a dynamic type
> cache miss, updated patches attached.  Only the clang patch has
> changed: added a parameter specifying this call should *always* be
> recovered from.
>
> Thanks!
>
> On Fri, Nov 30, 2012 at 5:58 PM, 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
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>


-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121130/d5d97f5e/attachment.html>