On Tue, Sep 30, 2014 at 10:33 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Tue, Sep 30, 2014 at 10:26:39AM -0700, Alexey Samsonov wrote: >> > 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. > > Would we accept -fsanitize-recover=undefined > -fno-sanitize-recover=signed-integer-overflow > as recovering everything but signed integer overflows, i.e. the decision > whether to recover a particular call would check similar bitmask as > is checked whether to sanitize something at all?
Yes, the logic for creating a set of recoverable sanitizers should be the same as the logic for creating a set of enabled sanitizers. -- Alexey Samsonov, Mountain View, CA
