On Thu, Dec 13, 2012 at 10:38:13AM +0400, Dmitry Vyukov wrote:
> On Wed, Dec 12, 2012 at 11:50 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.
Jakub
