On Fri, 2012-12-14 at 13:44 +0400, Dmitry Vyukov wrote: > On Thu, Dec 13, 2012 at 1:02 PM, Jakub Jelinek <ja...@redhat.com> wrote: > >> > Various TM tests ICE when built with -fgnu-tm -fsanitizer=address. > >> > The problem is that asan.c pass adds calls to builtins that weren't there > >> > before and TM is upset about it. The __asan_report* are all like > >> > abort, in correctly written program they shouldn't have a user visible > >> > effect, in bad program they will terminate the process, but in any case > >> > it doesn't matter how many times they are retried as part of a > >> > transaction, > >> > there is no state to roll back on transaction cancellation. > >> > __asan_handle_no_return, while not being noreturn, just marks the stack > >> > as > >> > unprotected, so again in correctly written application no effect, in bad > >> > app > >> > might result in some issues being undetected, but still, it can be done > >> > many > >> > times and isn't irreversible. > >> > >> I was only loosely following tm-languages discussions. Does gcc tm > >> model guarantees strong consistency for all memory accesses? I mean > >> there are tm implementations that allow transient inconsistencies, > > > > Will leave this to Torvald. > > > >> than are detected later and trx is restarted. Can't asan trigger false > >> positives in this case? > > > > I can't imagine any. > > > >> Also, what is the order of instrumentation in tm+asan setting? I mean > >> that neither tm must instrument asan instrumentation, nor asan must > >> instrument tm instrumentation. Is it the case? There also can be > >> conflicts related to ordering of instrumentation in the following > >> case: > >> asan_check(); > >> speculative_load(); > >> tm_check(); > > > > I'm not aware of TM having speculative loads, libgtm certainly doesn't > > install a SIGSEGV handler (and testing whether some memory is > > readable/writable without actually dereferencing would be terribly slow). > > If a memory load or store segfaults, whether in a transaction or outside of > > it, it is a program bug and it is right if asan terminates the program. > > > OK, thanks. > AFAIR tl2 installs SIGSEGV and uses non-failing loads.
I think the original implementation didn't, but other TL2 implementations might if they want to avoid providing full privatization safety without relying on any sandboxing attempts. Sandboxing is hard to get right (e.g., if the architecture doesn't provide nonfaulting loads), and if you try it, you end up with a much more intrusive solution (e.g., you need to ensure that the program doesn't override your signal handlers). Therefore, libitm ensures privatization safety by a quiescence-based approach (i.e., a privatizing transaction waits until all other active reading transactions are guaranteed to have observed the privatizer's updates). Torvald
