This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Make some asan builtins tm_pure (PR sanitizer/55508)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]