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: [tsan] ThreadSanitizer instrumentation part


Thanks, Fixed.

Wei.

On Wed, Nov 21, 2012 at 11:48 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Thu, Nov 22, 2012 at 11:45 AM, Xinliang David Li <davidxl@google.com>
> wrote:
>>
>> On Wed, Nov 21, 2012 at 11:35 PM, Dmitry Vyukov <dvyukov@google.com>
>> wrote:
>> > What percent of the memory accesses the following can skip?
>> >
>> > I just don't know what exactly they mean. ADDR_EXPR/COMPONENT_REF look
>> > like
>> > it can skip a lot.
>> >
>>
>> It does not skip a lot.
>>
>> >
>> > +  /* TODO: handle other cases
>> > +     (FIELD_DECL, ARRAY_RANGE_REF, TARGET_MEM_REF, ADDR_EXPR).  */
>>
>> The comment is not correct.  The analysis should not care about
>> FIELD_DECL (covered by COMPONENT_REF), nor ADDR_EXPR.  Due to the pass
>> ordering, target mem-ref is not seen either.
>
>
>
>
> Wei, please update the comment that only ARRAY_RANGE_REF is not handled.
>
>
>> > +  if (tcode != ARRAY_REF
>> > +      && tcode != VAR_DECL
>> > +      && tcode != COMPONENT_REF
>> > +      && tcode != INDIRECT_REF
>> > +      && tcode != MEM_REF)
>> > +    return false;
>> >
>>
>> The listed cases are handled.
>>
>> David
>>
>> >
>> >
>> > On Thu, Nov 22, 2012 at 11:29 AM, Dmitry Vyukov <dvyukov@google.com>
>> > wrote:
>> >>
>> >> +static bool
>> >> +tsan_gate (void)
>> >> +{
>> >> +  return flag_tsan != 0
>> >> + && builtin_decl_implicit_p (BUILT_IN_TSAN_INIT);
>> >>
>> >>
>> >> What does it mean? Why builtin_decl_implicit_p (BUILT_IN_TSAN_INIT)?
>> >>
>> >> +}
>> >>
>> >>
>> >>
>> >> On Thu, Nov 22, 2012 at 11:22 AM, Wei Mi <wmi@google.com> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I update the tsan patch against trunk, and create libtsan patch.
>> >>> Please see if it is ok.
>> >>>
>> >>> gcc/ChangeLog:
>> >>> 2012-11-22  Dmitry Vyukov  <dvyukov@google.com>
>> >>>             Wei Mi  <wmi@google.com>
>> >>>
>> >>>         * builtins.def (DEF_SANITIZER_BUILTIN): Define tsan builtins.
>> >>>         * sanitizer.def: Ditto.
>> >>>         * Makefile.in (tsan.o): Add tsan.o target.
>> >>>         (BUILTINS_DEF): Add sanitizer.def.
>> >>>         * passes.c (init_optimization_passes): Add tsan passes.
>> >>>         * tree-pass.h (register_pass_info): Ditto.
>> >>>         * toplev.c (compile_file): Ditto.
>> >>>         * doc/invoke.texi: Document tsan related options.
>> >>>         * gcc.c (LINK_COMMAND_SPEC): Add LIBTSAN_SPEC in link command
>> >>> if -fsanitize=thread.
>> >>>         * tsan.c: New file about tsan.
>> >>>         * tsan.h: Ditto.
>> >>>         * common.opt: Add -fsanitize=thread.
>> >>>
>> >>> libsanitizer/ChangeLog:
>> >>> 2012-11-22  Wei Mi  <wmi@google.com>
>> >>>
>> >>>         * tsan: New directory. Import tsan runtime from llvm.
>> >>>         * configure.ac: Add 64 bits tsan build.
>> >>>         * Makefile.am: Likewise.
>> >>>         * configure: Regenerated.
>> >>>         * Makefile.in: Likewise.
>> >>>
>> >>> Thanks,
>> >>> Wei.
>> >>>
>> >>> On Sun, Nov 18, 2012 at 10:52 AM, Konstantin Serebryany
>> >>> <konstantin.s.serebryany@gmail.com> wrote:
>> >>> > Just a comment about tsan.
>> >>> > Today, tsan works *only* on x86_64 linux (no 32-bits, no non-linux).
>> >>> > Other 64-bit platforms may be doable, but not as easy as for asan.
>> >>> > Non-linux is harder than non-x86_64 (need to support tons of libc
>> >>> > interceptors).
>> >>> > 32-bit platforms are very hard to port to, I would not bother for
>> >>> > now.
>> >>> > (this probably includes x32, which has cheap atomic 64-bit
>> >>> > loads/stores, but has too small address space for tsan)
>> >>> >
>> >>> > Conclusion: when committing tsan code, please make sure it is enable
>> >>> > only on x86_64
>> >>> >
>> >>> > --kcc
>> >>> >
>> >>> > On Sat, Nov 17, 2012 at 3:13 AM, Wei Mi <wmi@google.com> wrote:
>> >>> >> Hi,
>> >>> >>
>> >>> >> Is it ok for the trunk?
>> >>> >>
>> >>> >> Thanks,
>> >>> >> Wei.
>> >>> >>
>> >>> >> On Tue, Nov 13, 2012 at 5:06 PM, Wei Mi <wmi@google.com> wrote:
>> >>> >>> Thanks for catching this. I update the patch.
>> >>> >>>
>> >>> >>> Regards,
>> >>> >>> Wei.
>> >>> >>>
>> >>> >>> On Tue, Nov 13, 2012 at 4:54 PM, Richard Henderson
>> >>> >>> <rth@redhat.com>
>> >>> >>> wrote:
>> >>> >>>> On 11/13/2012 04:08 PM, Wei Mi wrote:
>> >>> >>>>> +extern void tsan_finish_file (void);
>> >>> >>>>> +
>> >>> >>>>> +#endif /* TREE_TSAN */
>> >>> >>>>> +/* ThreadSanitizer, a data race detector.
>> >>> >>>>> +   Copyright (C) 2011 Free Software Foundation, Inc.
>> >>> >>>>> +   Contributed by Dmitry Vyukov <dvyukov@google.com>
>> >>> >>>>
>> >>> >>>> Careful, you've got double applied patches there.
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> r~
>> >>
>> >>
>> >
>
>


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