On Wed, Oct 1, 2014 at 10:58 PM, Jakub Jelinek wrote:
> On Wed, Oct 01, 2014 at 04:21:29PM -0700, Alexey Samsonov wrote:
>> Speaking of plain -f(no-)sanitize-recover - it would probably be
>> better to change the semantics of this flag,
>> so that "-f(no-)?sanitize-recover" means "enable(disable)
On Wed, Oct 01, 2014 at 04:21:29PM -0700, Alexey Samsonov wrote:
> Speaking of plain -f(no-)sanitize-recover - it would probably be
> better to change the semantics of this flag,
> so that "-f(no-)?sanitize-recover" means "enable(disable) recovery for
> all sanitizers enabled at this point".
> That
Speaking of plain -f(no-)sanitize-recover - it would probably be
better to change the semantics of this flag,
so that "-f(no-)?sanitize-recover" means "enable(disable) recovery for
all sanitizers enabled at this point".
That is, it would be pretty much like -Werror flag.
For example,
"-fsanitize=u
On Tue, Sep 30, 2014 at 10:36:34AM -0700, Alexey Samsonov wrote:
> > 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 simi
On Tue, Sep 30, 2014 at 10:33 AM, Jakub Jelinek 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 r
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 prominin
On Tue, Sep 30, 2014 at 12:07 AM, Yury Gribov 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).
>>>
>>
On 09/30/2014 10:56 AM, Yury Gribov wrote:
On 09/30/2014 04:24 AM, Konstantin Serebryany wrote:
On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov
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 wit
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-thres
On 09/30/2014 04:24 AM, Konstantin Serebryany wrote:
On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov 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
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 call
On Mon, Sep 29, 2014 at 6:05 PM, Alexey Samsonov wrote:
> On Mon, Sep 29, 2014 at 5:24 PM, Konstantin Serebryany
> wrote:
>>
>> On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov wrote:
>> > On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek wrote:
>> >> On Mon, Sep 29, 2014 at 03:36:20PM -0700, Alex
On Mon, Sep 29, 2014 at 5:24 PM, Konstantin Serebryany
wrote:
>
> On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov wrote:
> > On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek wrote:
> >> On Mon, Sep 29, 2014 at 03:36:20PM -0700, Alexey Samsonov wrote:
> >>> -fasan-recover doesn't look like a good
On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov wrote:
> On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek 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,
On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek 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
>>
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
(resending in plain-text mode)
-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 sing
+Alexey Samsonov
On Mon, Sep 29, 2014 at 10:43 AM, Jakub Jelinek wrote:
> On Mon, Sep 29, 2014 at 09:21:11PM +0400, Yury Gribov wrote:
>> >>This patch enables -fsanitize-recover for KASan by default. This causes
>> >>KASan to continue execution after error in case of inline
>> >>instrumentation.
On Mon, Sep 29, 2014 at 09:21:11PM +0400, Yury Gribov wrote:
> >>This patch enables -fsanitize-recover for KASan by default. This causes
> >>KASan to continue execution after error in case of inline
> >>instrumentation. This feature is needed because
> >>- reports during early bootstrap won't even
Hi all,
This patch enables -fsanitize-recover for KASan by default. This causes
KASan to continue execution after error in case of inline
instrumentation. This feature is needed because
- reports during early bootstrap won't even be printed
- needed to run all tests w/o rebooting machine for eve
20 matches
Mail list logo
