This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Make some asan builtins tm_pure (PR sanitizer/55508)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Dmitry Vyukov <dvyukov at google dot com>
- Cc: Dodji Seketeli <dseketel at redhat dot com>, Kostya Serebryany <kcc at google dot com>, Aldy Hernandez <aldyh at redhat dot com>, Torvald Riegel <triegel at redhat dot com>, Richard Henderson <rth at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 13 Dec 2012 10:02:07 +0100
- Subject: Re: [PATCH] Make some asan builtins tm_pure (PR sanitizer/55508)
- References: <20121212195033.GE2315@tucnak.redhat.com> <CACT4Y+Yo+LJ4g_jMkeFP7upyLJANohr2uw_yPXVtdAm51POa9w@mail.gmail.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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