This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCHv3][PING] Enable -fsanitize-recover for KASan
- From: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- To: Alexey Samsonov <samsonov at google dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Yury Gribov <y dot gribov at samsung dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Dmitry Vyukov <dvyukov at google dot com>, Andrey Ryabinin <a dot ryabinin at samsung dot com>, Konstantin Khlebnikov <k dot khlebnikov at samsung dot com>
- Date: Mon, 29 Sep 2014 18:48:38 -0700
- Subject: Re: [PATCHv3][PING] Enable -fsanitize-recover for KASan
- Authentication-results: sourceware.org; auth=none
- References: <54095E23 dot 6050900 at samsung dot com> <5416B3A2 dot 4050200 at samsung dot com> <54299507 dot 7090800 at samsung dot com> <20140929174357 dot GH17454 at tucnak dot redhat dot com> <CAGQ9bdzcCO6CfQ7nG+xeAh63fs-GASiTExTvZfjJtMA67_4feQ at mail dot gmail dot com> <CAGSYnCPwbgZ++2Jt2vE6-ytveSJwSQPZT5umLeKPVWsVjWzwPQ at mail dot gmail dot com> <20140929231720 dot GI17454 at tucnak dot redhat dot com> <CAGSYnCPAN83v+JOyw-jMLUEE2YjaNQykdTCG4rdd=o_ieC4vFA at mail dot gmail dot com> <CAGQ9bdyWWNMt4m9jO2N1nzvVFjVuT1zbyey362WvnMxJZmNkBw at mail dot gmail dot com> <CAGSYnCOen-gDsT6X8Rxa9E7px=Jz-X70Y7yRHwRoxtdruAG4=g at mail dot gmail dot com>
On Mon, Sep 29, 2014 at 6:05 PM, Alexey Samsonov <samsonov@google.com> wrote:
> On Mon, Sep 29, 2014 at 5:24 PM, Konstantin Serebryany
> <konstantin.s.serebryany@gmail.com> wrote:
>>
>> On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov <samsonov@google.com> wrote:
>> > On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> >> On Mon, Sep 29, 2014 at 03:36:20PM -0700, Alexey Samsonov wrote:
>> >>> -fasan-recover doesn't look like a good idea - for instance, in Clang, we
>> >>> never use "?san"
>> >>> in flag names, preferring -fsanitize-whatever. What's the rationale behind
>> >>> splitting
>> >>> -fsanitize-recover in two flags (ASan- and UBSan- specific)?
>> >>> Is there no way to keep a single -f(no-)sanitize-recover for that purpose?
>> >>> Now it works
>> >>> only for UBSan checks, but we may extend it to another sanitizers as well.
>> >>
>> >> The problem is that if we start using it for ASan, it needs to have a
>> >> different default, because ASan wants to abort by default, while UBSan
>> >> recover by default. -fsanitize=kernel-address w (KASan) wants to recover
>> >> by default. So, the option is either to never support recover for
>> >> -fsanitize=address, for ubsan keep -fsanitize-recover (by default) as is
>> >> and for kasan use that same switch, or have separate flags.
>> >>
>> >> Jakub
>> >
>> > 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)
>> we can and probably will allow to recover from errors (glibc demands that),
>> but that does not require any compile-time flag.
>
>
> So, if we switch to instrumentation to callbacks (which are not
> necessarily noreturn),
> -fsanitize-recover is the thing we plan to support?
Yes, but this will not involve any additional compile-time flag
>
>>
>>
>>
>> > 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.
>> Which default setting is stronger? :)
>
> We can preserve the default behavior for each tool (no recovery for
> ASan, recovery for UBSan)
> unless recovery mode is explicitly specified.
>
>>
>> > -fsanitize=kernel-address. We can, potentially, extend
>> > -fsanitize-recover flag to take the same values as -fsanitize= one,
>> > so that one can specify which sanitizers are recoverable, and which
>> > are not, but I'd try to make this a last resort - this is too complex.
>> >
>> > --
>> > Alexey Samsonov, Mountain View, CA
>
>
>
>
> --
> Alexey Samsonov, Mountain View, CA