[PATCHv3][PING] Enable -fsanitize-recover for KASan

[Alexey Samsonov]

On Tue, Sep 30, 2014 at 10:33 AM, Jakub Jelinek <jakub@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