On Tue, Sep 30, 2014 at 12:07 AM, Yury Gribov <y.gri...@samsung.com> wrote: > On 09/30/2014 09:40 AM, Jakub Jelinek wrote: >> >> On Mon, Sep 29, 2014 at 05:24:02PM -0700, Konstantin Serebryany wrote: >>>> >>>> I don't think we ever going to support recovery for regular ASan >>>> (Kostya, correct me if I'm wrong). >>> >>> >>> I hope so too. >>> Another point is that with asan-instrumentation-with-call-threshold=0 >>> (instrumentation with callbacks) >> >> >> The normal (non-recovery) callbacks are __attribute__((noreturn)) for >> performance reasons, and you do need different callbacks and different >> generated code if you want to recover (after the callback you need jump >> back to a basic block after the conditional jump). >> So, in that case you would need -fsanitize-recover=address. >> >>>> I see no problem in enabling -fsanitize-recover by default for >>>> -fsanitize=undefined and >>> >>> >>> This becomes more interesting when we use asan and ubsan together. >> >> >> That is fairly common case. > > > I think we can summarize: > * the current option -fsanitize-recover is misleading; it's really > -fubsan-recover > * we need a way to selectively enable/disable recovery for different > sanitizers > > The most promininet solution seems to be > * allow -fsanitize-recover=tgt1,tgt2 syntax > * -fsanitize-recover wo options would still mean UBSan recovery > > The question is what to do with -fno-sanitize-recover then.
We can make -f(no-)?sanitize-recover= flags accept the same values as -f(no-)?sanitize= flags. In this case, "-fsanitize-recover" will be a deprecated alias of "-fsanitize-recover=undefined", and "-fno-sanitize-recover" will be a deprecated alias of "-fno-sanitize-recover=undefined". If a user provides "-fsanitize-recover=address", we can instruct the instrumentation pass to use recoverable instrumentation. > > -Y > -- Alexey Samsonov, Mountain View, CA
