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.
-Y
