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. Richard.
