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