This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix -fsanitize=thread with -fnon-call-exceptions (PR sanitizer/80110)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Dmitry Vyukov <dvyukov at google dot com>, Dodji Seketeli <dseketel at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 22 Mar 2017 14:44:03 +0100
- Subject: Re: [PATCH] Fix -fsanitize=thread with -fnon-call-exceptions (PR sanitizer/80110)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 827F366CAC
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 827F366CAC
- References: <20170320212603.GQ11094@tucnak> <alpine.LSU.2.20.1703210911400.30051@zhemvz.fhfr.qr> <20170321082149.GU11094@tucnak> <alpine.LSU.2.20.1703210924520.30051@zhemvz.fhfr.qr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Mar 21, 2017 at 09:26:49AM +0100, Richard Biener wrote:
> On Tue, 21 Mar 2017, Jakub Jelinek wrote:
>
> > On Tue, Mar 21, 2017 at 09:12:51AM +0100, Richard Biener wrote:
> > > > libtsan atomics aren't throwing, so if we transform atomics which
> > > > are throwing with -fnon-call-exceptions, we need to clean up EH stuff.
> > > >
> > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > >
> > > Huh, but this means with TSAN we create wrong-code with
> > > -fnon-call-exceptions and programs will crash instead of properly
> > > catching things like null-pointer accesses?
> >
> > True. I think it is only about atomics, normal loads/stores are done
> > inline with extra calls before/after that just tell the library about
> > those loads/stores (though not sure what the library code will do with
> > invalid or NULL pointers, if it won't crash on them).
> > The question is what we could do about it and if it is worth bothering,
> > I guess we'd need to build tsan_interface_atomics.cc with
> > -fnon-call-exceptions and the question would be if it doesn't slow it
> > down for the common case where -fnon-call-exceptions isn't used.
> > Another option would be to add another set of __tsan_atomic* entrypoints
> > for -fnon-call-exceptions.
> >
> > > We should at least document this or reject sanitize=thread with
> > > -fnon-call-exceptions.
> >
> > Rejecting would mean that even code that doesn't use the atomics or doesn't
> > use atomics on invalid pointers would not be allowed.
>
> Indeed. So maybe just document it then. I suppose sanitizing in
> general has the issue that its events are not properly raising
> exceptions (of whatever kind), so documenting that programs relying
> on async EH to be reliably delivered may not work as expected with
> sanitization would be good.
So like this in addition to the posted patch?
2017-03-22 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/80110
* doc/invoke.texi (-fsanitize=thread): Document that with
-fnon-call-exceptions atomics are not able to throw
exceptions.
--- gcc/doc/invoke.texi.jj 2017-03-19 11:57:08.000000000 +0100
+++ gcc/doc/invoke.texi 2017-03-22 14:22:40.737505684 +0100
@@ -10761,6 +10761,10 @@ supported options.
The option can't be combined with @option{-fsanitize=address},
@option{-fsanitize=leak} and/or @option{-fcheck-pointer-bounds}.
+Note that sanitized atomic builtins cannot throw exceptions when
+operating on invalid memory addresses with non-call exceptions
+(@option{-fnon-call-exceptions}).
+
@item -fsanitize=leak
@opindex fsanitize=leak
Enable LeakSanitizer, a memory leak detector.
Jakub