Hi Jack,
Koysta mentioned in a previous mail that tsan is only supported on
x86_64 linux (no 32-bits, no non-linux) for now. tsan building should
be disabled on the platforms other than x86-64-linux. Thanks to Jakub
who will provide another patch including this fix soon.
Thanks,
Wei.
On Thu, Nov
On Thu, Nov 22, 2012 at 02:08:07PM -0800, Wei Mi wrote:
> Thanks. I checked in the code.
> Committed revision 193736.
> Committed revision 193737.
>
> Wei.
Wei,
Unlike libasan, we seem to have issues building libtsan on darwin using the
currently proposed
patch...
http://gcc.gnu.org/ml/gcc-p
On Thu, Nov 22, 2012 at 03:04:23PM -0800, H.J. Lu wrote:
> It failed to bootstrap on Linux/i686:
>
> http://gcc.gnu.org/ml/gcc-regression/2012-11/msg00409.html
>
> It tried to build tsan on Linux/i686.
I'd hope http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01866.html ought to
fix that.
J
On Thu, Nov 22, 2012 at 2:08 PM, Wei Mi wrote:
> Thanks. I checked in the code.
> Committed revision 193736.
> Committed revision 193737.
>
> Wei.
>
> On Thu, Nov 22, 2012 at 1:54 AM, Jakub Jelinek wrote:
>> On Wed, Nov 21, 2012 at 11:22:51PM -0800, Wei Mi wrote:
>>> I update the tsan patch again
Thanks. I checked in the code.
Committed revision 193736.
Committed revision 193737.
Wei.
On Thu, Nov 22, 2012 at 1:54 AM, Jakub Jelinek wrote:
> On Wed, Nov 21, 2012 at 11:22:51PM -0800, Wei Mi wrote:
>> I update the tsan patch against trunk, and create libtsan patch.
>> Please see if it is ok.
Thanks, Fixed.
Wei.
On Wed, Nov 21, 2012 at 11:48 PM, Dmitry Vyukov wrote:
> On Thu, Nov 22, 2012 at 11:45 AM, Xinliang David Li
> wrote:
>>
>> On Wed, Nov 21, 2012 at 11:35 PM, Dmitry Vyukov
>> wrote:
>> > What percent of the memory accesses the following can skip?
>> >
>> > I just don't know
On Wed, Nov 21, 2012 at 11:22:51PM -0800, Wei Mi wrote:
> I update the tsan patch against trunk, and create libtsan patch.
> Please see if it is ok.
>
> gcc/ChangeLog:
> 2012-11-22 Dmitry Vyukov
> Wei Mi
>
> * builtins.def (DEF_SANITIZER_BUILTIN): Define tsan builtins.
>
On Thu, Nov 22, 2012 at 11:29:05AM +0400, Dmitry Vyukov 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)?
It is a temporary workaround, I'l
On Wed, Nov 21, 2012 at 11:35 PM, Dmitry Vyukov 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_DE
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
Hi,
Is it ok for the trunk?
Thanks,
Wei.
On Tue, Nov 13, 2012 at 5:06 PM, Wei Mi wrote:
> Thanks for catching this. I update the patch.
>
> Regards,
> Wei.
>
> On Tue, Nov 13, 2012 at 4:54 PM, Richard Henderson wrote:
>> On 11/13/2012 04:08 PM, Wei Mi wrote:
>>> +extern void tsan_finish_file (
Thanks for catching this. I update the patch.
Regards,
Wei.
On Tue, Nov 13, 2012 at 4:54 PM, Richard Henderson 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
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
Careful, you've got double applied patches there.
r
On Tue, Nov 13, 2012 at 9:36 AM, Jakub Jelinek wrote:
> On Tue, Nov 13, 2012 at 09:25:36AM -0800, Xinliang David Li wrote:
>> > That is complete misunderstanding of what update_address_taken does.
>> > It removes TREE_ADDRESSABLE from addressables that are no longer
>> > addressable, rather than a
On Tue, Nov 13, 2012 at 09:25:36AM -0800, Xinliang David Li wrote:
> > That is complete misunderstanding of what update_address_taken does.
> > It removes TREE_ADDRESSABLE from addressables that are no longer
> > addressable, rather than adding TREE_ADDRESSABLE bits.
>
> It will do the latter too.
On Tue, Nov 13, 2012 at 8:40 AM, Jakub Jelinek wrote:
> On Mon, Nov 05, 2012 at 04:37:41PM -0800, Wei Mi wrote:
>> Thanks for the comments. I fix most of them except the setting of
>> TODO_ The new patch.txt is attached.
>
> Please update the patch against trunk, it doesn't apply cleanly becau
On Mon, Nov 05, 2012 at 04:37:41PM -0800, Wei Mi wrote:
> Thanks for the comments. I fix most of them except the setting of
> TODO_ The new patch.txt is attached.
Please update the patch against trunk, it doesn't apply cleanly because
of the asan commit. I took the liberty to do at least some
For TODO_update_ssa, when we insert tsan_write(&a), current function's
ssa_renaming_needed flag will be set in finalize_ssa_defs because we
insert non-ssaname vdef. An assertion in execute_todo will check
whether we have TODO_update_ssa set when current function's
ssa_renaming_needed flag is set. T
Hi Jakub,
Thanks for the comments. I fix most of them except the setting of
TODO_ The new patch.txt is attached.
Thanks,
Wei.
>> + TODO_verify_all | TODO_update_ssa
>
> Ideally you shouldn't need TODO_update_ssa.
>
I got error when I removed TODO_update_ssa, so I kept it.
>> +| TODO_u
On Sat, Nov 03, 2012 at 10:05:35AM -0700, Wei Mi wrote:
> --- gcc/sanitizer.def (revision 0)
> +++ gcc/sanitizer.def (revision 0)
> @@ -0,0 +1,31 @@
> +DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_WRITE_16, "__tsan_write16",
> + BT_FN_VOID_PTR, ATTR_NOTHROW_LEAF_LIST)
> +
> +
> +
Pleas
Sorry, I attached an incorrect patch.txt yesterday. This is the correct one.
Thanks,
Wei.
On Fri, Nov 2, 2012 at 6:31 PM, Wei Mi wrote:
> Hi,
>
> Thanks for so many useful comments! I update the file according to the
> comments. The major changes include adding sanitizer.def and
> generating gim
Hi,
Thanks for so many useful comments! I update the file according to the
comments. The major changes include adding sanitizer.def and
generating gimple directly. New patch file is attached.
> On Wed, Oct 31, 2012 at 11:34:10AM -0700, Wei Mi wrote:
>> gcc/ChangeLog:
>> 2012-10-31 Wei Mi
>
> I
Yes, agree. For now using the !(TREE_ADDRESSABLE (decl) ||
is_global_var (decl)) can be used to skip instrumentation if the
points-to interface is not available for use.
David
On Fri, Nov 2, 2012 at 8:58 AM, Jakub Jelinek wrote:
> On Fri, Nov 02, 2012 at 08:54:42AM -0700, Xinliang David Li wro
On Fri, Nov 02, 2012 at 08:54:42AM -0700, Xinliang David Li wrote:
> Thanks, good to know that.
But note that such vars, even when accessed only partially, don't
need to be tracked by tsan just because of that.
TREE_ADDRESSABLE (decl) || is_global_var (decl) is really a conservative
check for what
Thanks, good to know that.
David
On Fri, Nov 2, 2012 at 6:31 AM, Martin Jambor wrote:
> Hi,
>
> On Thu, Nov 01, 2012 at 11:11:13AM -0700, Xinliang David Li wrote:
>>
>
> ...
>
>> The TREE_ADDRESSABLE check seems redundant -- if the var_decl (instead
>> of ssa name) appears in the assignment, why
Hi,
On Thu, Nov 01, 2012 at 11:11:13AM -0700, Xinliang David Li wrote:
>
...
> The TREE_ADDRESSABLE check seems redundant -- if the var_decl (instead
> of ssa name) appears in the assignment, why would it not be
> 'addressable'?
There are other reason beside being TREE_ADDRESSABLE that may ca
It is not always true though -- only when the array address is picked
by the pass to be the induction variable.
David
On Thu, Nov 1, 2012 at 2:24 PM, Jakub Jelinek wrote:
> On Thu, Nov 01, 2012 at 02:19:43PM -0700, Xinliang David Li wrote:
>> Right -- I found the same thing, it is the ivopt that
On Thu, Nov 01, 2012 at 02:19:43PM -0700, Xinliang David Li wrote:
> Right -- I found the same thing, it is the ivopt that resets it -- the
> IV opt pass should have a TODO_update_address_taken.
That wouldn't change anything. The IVopts pass adds some_ptr = &a[0];
to the IL, so a is then address
Right -- I found the same thing, it is the ivopt that resets it -- the
IV opt pass should have a TODO_update_address_taken.
thanks,
David
On Thu, Nov 1, 2012 at 2:07 PM, Jakub Jelinek wrote:
> On Thu, Nov 01, 2012 at 01:57:40PM -0700, Xinliang David Li wrote:
>> I looked at it pretty late in th
On Thu, Nov 01, 2012 at 01:57:40PM -0700, Xinliang David Li wrote:
> I looked at it pretty late in the pipeline -- during cfgexpand and I
> had specified -O2 in the command line.
That was too late, ivopts pass (after pre where tsan pass was put around)
marks it TREE_ADDRESSABLE again, because it c
On Thu, Nov 1, 2012 at 1:47 PM, Jakub Jelinek wrote:
> On Thu, Nov 01, 2012 at 12:34:54PM -0700, Xinliang David Li wrote:
>> On Thu, Nov 1, 2012 at 12:16 PM, Jakub Jelinek wrote:
>> > On Thu, Nov 01, 2012 at 11:57:21AM -0700, Xinliang David Li wrote:
>> >> That is exactly related to tsan -- it sh
On Thu, Nov 01, 2012 at 12:34:54PM -0700, Xinliang David Li wrote:
> On Thu, Nov 1, 2012 at 12:16 PM, Jakub Jelinek wrote:
> > On Thu, Nov 01, 2012 at 11:57:21AM -0700, Xinliang David Li wrote:
> >> That is exactly related to tsan -- it should skip local variable that
> >> is not address taken (th
On Thu, Nov 01, 2012 at 11:35:42PM +0400, Dmitry Vyukov wrote:
> Wow! It's cool!
> Is it costly to compute?
No, it is just a couple of instructions and bitmap_bit_p test.
Jakub
On Thu, Nov 1, 2012 at 12:16 PM, Jakub Jelinek wrote:
> On Thu, Nov 01, 2012 at 11:57:21AM -0700, Xinliang David Li wrote:
>> That is exactly related to tsan -- it should skip local variable that
>> is not address taken (though still addressable, which by addressable,
>> it means the variable has
On Thu, Nov 01, 2012 at 11:57:21AM -0700, Xinliang David Li wrote:
> That is exactly related to tsan -- it should skip local variable that
> is not address taken (though still addressable, which by addressable,
> it means the variable has a memory home).
>
> The problem is that if 'addressable' bi
That is exactly related to tsan -- it should skip local variable that
is not address taken (though still addressable, which by addressable,
it means the variable has a memory home).
The problem is that if 'addressable' bit is not equivalent to 'address
taken', it will be too conservative to use it
On Thu, Nov 01, 2012 at 11:32:01AM -0700, Xinliang David Li wrote:
> For the following case:
>
> int foo()
> {
>int a[100];
>
> // use 'a' as a[i]
> ...
> }
>
> Assuming there is no assignment of the form p = &a[i] in the source,
> variable 'a' still will be allocated in stack and it
For the following case:
int foo()
{
int a[100];
// use 'a' as a[i]
...
}
Assuming there is no assignment of the form p = &a[i] in the source,
variable 'a' still will be allocated in stack and its address is is
needed. Is the addressable bit set for 'a'? If yes, then it is not
the sa
On Thu, Nov 01, 2012 at 11:11:13AM -0700, Xinliang David Li wrote:
> But it skips those globals without static storage and marked as not
> addressable.
>
> It seems to me you want to skip all stack local variables that are not
> address escaped. Without address escape analysis, the address taken
On Thu, Nov 1, 2012 at 2:11 PM, Xinliang David Li wrote:
> The TREE_ADDRESSABLE check seems redundant -- if the var_decl (instead
> of ssa name) appears in the assignment, why would it not be
> 'addressable'? And being addressable does not mean it is address taken
> either.
Yes, it does mean tha
On Thu, Nov 1, 2012 at 11:16 AM, Dmitry Vyukov wrote:
> On Thu, Nov 1, 2012 at 10:14 PM, Dmitry Vyukov wrote:
>>>
>>> >> > On Wed, Oct 31, 2012 at 11:00:17PM -0700, Xinliang David Li wrote:
>>> >> >> > + /* Below are things we do not instrument
>>> >> >> > + (no possibility of races or not i
On Thu, Nov 1, 2012 at 10:06 AM, Dmitry Vyukov wrote:
> On Thu, Nov 1, 2012 at 7:47 PM, Xinliang David Li
> wrote:
>>
>> On Wed, Oct 31, 2012 at 11:27 PM, Jakub Jelinek wrote:
>> > On Wed, Oct 31, 2012 at 11:00:17PM -0700, Xinliang David Li wrote:
>> >> > + /* Below are things we do not instrum
On Wed, Oct 31, 2012 at 11:27 PM, Jakub Jelinek wrote:
> On Wed, Oct 31, 2012 at 11:00:17PM -0700, Xinliang David Li wrote:
>> > + /* Below are things we do not instrument
>> > + (no possibility of races or not implemented yet). */
>> > + if (/* Compiler-emitted artificial variables. */
>>
On Thu, Nov 01, 2012 at 10:01:31AM +0400, Dmitry Vyukov wrote:
> > For gimplification context, see above, would be better to just
> > emit gimple directly.
> > For func_calls and func_mops, I believe why you need two variables instead
> > of just one, and why the function can't just return a bool w
On Wed, Oct 31, 2012 at 11:34:10AM -0700, Wei Mi wrote:
+static tree
+get_init_decl (void)
+{
+ tree typ;
+ static tree decl;
+
+ if (decl != NULL)
+return decl;
+ typ = build_function_type_list (void_type_node, NULL_TREE);
+ decl = build_func_decl (typ, "__tsan_init");
+ return decl;
+}
On Wed, Oct 31, 2012 at 11:00:17PM -0700, Xinliang David Li wrote:
> > + /* Below are things we do not instrument
> > + (no possibility of races or not implemented yet). */
> > + if (/* Compiler-emitted artificial variables. */
> > + (DECL_P (expr) && DECL_ARTIFICIAL (expr))
> > +
On Wed, Oct 31, 2012 at 4:10 PM, Jakub Jelinek wrote:
> Hi!
>
> Just a couple of random comments:
>
> On Wed, Oct 31, 2012 at 11:34:10AM -0700, Wei Mi wrote:
>> gcc/ChangeLog:
>> 2012-10-31 Wei Mi
>
> If Dmitry wrote parts of the patch, it would be nice to mention
> him in the ChangeLog too.
>
> --fno-default-inline @gol
> +-fmove-loop-invariants -fmudflap -fmudflapir -fmudflapth
> -fno-branch-count-reg @gol
> +-ftsan -ftsan-ignore -fno-default-inline @gol
Change -ftsan to -fthread-sanitizer
> -fno-defer-pop -fno-function-cse -fno-guess-branch-probability @gol
> -fno-inline -fno-mat
Hi!
Just a couple of random comments:
On Wed, Oct 31, 2012 at 11:34:10AM -0700, Wei Mi wrote:
> gcc/ChangeLog:
> 2012-10-31 Wei Mi
If Dmitry wrote parts of the patch, it would be nice to mention
him in the ChangeLog too.
> * Makefile.in (tsan.o): New
> * passes.c (init_optimi
Hi,
The patch is about ThreadSanitizer. ThreadSanitizer is a data race
detector for C/C++ programs. It contains two parts: instrumentation
and runtime library. This patch is the first part, and runtime will be
included in the second part. Dmitry(dvyu...@google.com) is the author
of this part, and
50 matches
Mail list logo
