On Wed, May 13, 2020 at 12:48 PM Marco Elver wrote:
> > Hello, Jakub,
> >
> > On Tue, 28 Apr 2020 at 16:58, Dmitry Vyukov wrote:
> > >
> > > On Tue, Apr 28, 2020 at 4:55 PM Jakub Jelinek wrote:
> > > >
> > > > On Tue, Apr 28, 2020 at 0
On Tue, Apr 28, 2020 at 4:55 PM Jakub Jelinek wrote:
>
> On Tue, Apr 28, 2020 at 04:48:31PM +0200, Dmitry Vyukov wrote:
> > FWIW this is:
> >
> > Acked-by: Dmitry Vyukov
> >
> > We just landed a similar change to llvm:
> > h
y marked variables in the kernel, for
> example bit-flags (here we may hide 'volatile' behind a different name
> such as 'no_data_race').
>
> [1] https://github.com/google/ktsan/wiki/KCSAN
> [2]
> https://lkml.kernel.org/r/CANpmjNOfXNE-Zh3MNP=-gmnhvKbsfUfTtWky
Some stats from kernel build for number of trace_cmp callbacks:
gcc
non-const: 38051
const: 272726
total: 310777
clang:
non-const: 45944
const: 266299
total: 312243
The total is quite close. Gcc seems to emit more const callbacks, which is good.
On Tue, Sep 12, 2017 at 4:32 PM, Dmitry Vyukov
On Thu, Sep 7, 2017 at 9:02 AM, 吴潍浠(此彼) wrote:
> Hi
> The trace-div and trace-gep options seems be used to evaluate corpus
> to trigger specific kind of bugs. And they don't have strong effect to
> coverage.
>
> The trace-pc-guard is useful, but it may be much more complex than trace-pc.
> I thin
;
>
> On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov wrote:
>> On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote:
>>> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote:
>>>> What we instrument in LLVM is _comparisons_ rather than control
>>>
On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov wrote:
> On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote:
>> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote:
>>> What we instrument in LLVM is _comparisons_ rather than control
>>> structures. So that w
On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote:
> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote:
>> What we instrument in LLVM is _comparisons_ rather than control
>> structures. So that would be:
>> _4 = x_8(D) == 98;
>> For example, resu
thing else that needs to be
> conditionalized.
>
> @@ -1943,6 +2032,12 @@ common_handle_option (struct gcc_options *opts,
> &= ~(SANITIZE_UNDEFINED | SANITIZE_UNDEFINED_NONDEFAULT);
>break;
>
> +case OPT_fsanitize_coverage_:
> + opts->x_flag_sanitize_coverage
> + = parse_coverage_sanitizer_o
On Sat, Aug 5, 2017 at 11:53 AM, 吴潍浠(此彼) wrote:
> Hi all
> Is it worth adding my codes to gcc ? Are there some steps I need to do ?
> Could somebody tell me the progress ?
FYI, we've mailed a Linux kernel change that uses this instrumentation:
https://groups.google.com/forum/#!topic/syzkaller/r0
On Sat, Jul 15, 2017 at 9:21 AM, 吴潍浠(此彼) wrote:
> Hi
>
> Implementing __sanitizer_cov_trace_cmp[1248]_const is OK .
> And I will try to find some determinate way to judge this comparison is for
> loop or not.
> Because all the loops(for() or while()) seem to be transformed to "if" and
> "goto" b
On Fri, Jul 14, 2017 at 11:17 PM, Kostya Serebryany wrote:
> Hi
>
> I wrote a test for "-fsanitize-coverage=trace-cmp" .
>
> Is there anybody tells me if these codes could be merged into gcc ?
Nice!
We are currently working on Linux kernel fuzzing
On Thu, Jul 13, 2017 at 11:18 PM, Kostya Serebryany wrote:
>> > Hi
>> >
>> > I wrote a test for "-fsanitize-coverage=trace-cmp" .
>> >
>> > Is there anybody tells me if these codes could be merged into gcc ?
>>
>>
>> Nice!
>>
>> We are currently working on Linux kernel fuzzing that use the
>> comp
>> meaningful, because programmers must have some reasons to do that. As
>> practice , "==" is more meaningful.
>>
>> 4.Should we record comparisons for counting loop checks ?
>> Not sure.
>>
>> With Regards
>> Wish Wu of Ant-financial Li
On Tue, Jul 11, 2017 at 1:59 PM, Wish Wu wrote:
> Hi
>
> I wrote a test for "-fsanitize-coverage=trace-cmp" .
>
> Is there anybody tells me if these codes could be merged into gcc ?
Nice!
We are currently working on Linux kernel fuzzing that use the
comparison tracing. We use clang at the momen
On Wed, Dec 7, 2016 at 10:57 PM, Sandra Loosemore
wrote:
> On 12/07/2016 12:30 PM, Dmitry Vyukov wrote:
>>
>> On Wed, Dec 7, 2016 at 8:23 PM, Sandra Loosemore
>> wrote:
>>>
>>>
>>> You need to fix doc/invoke.texi as well to reflect this cha
On Wed, Dec 7, 2016 at 8:23 PM, Sandra Loosemore
wrote:
> On 12/07/2016 11:44 AM, Dmitry Vyukov wrote:
>>
>> Hello,
>>
>> Revision 241896 added -fsanitize-address-use-after-scope and enabled
>> it whenever any sanitizer is enabled. This caused problems for kernel
ize-address-use-after-scope for e.g. -fsanitize=thread, which
is I believe unnecessary.
OK for trunk?
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 243344)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2016-12-07 Dmitry Vyukov
On Mon, Feb 15, 2016 at 8:22 PM, Mike Stump wrote:
> On Feb 15, 2016, at 3:29 AM, Bernd Edlinger wrote:
>> And independently of that I am looking at using llvm's test.h framework
>> instead
>> of gcc's test_barrier.h for gcc-7 soon.
>
> Here’s to hoping that we don’t back slide on:
>
> https:/
On Mon, Feb 15, 2016 at 1:44 PM, Bernd Edlinger
wrote:
> On 15/02/16 13:05, Dmitry Vyukov wrote:
>> On Mon, Feb 15, 2016 at 12:29 PM, Bernd Edlinger
>> wrote:
>>>
>>> No problem. PR65400 was a GCC wrong code bug, so it makes no
>>> sense to have the sam
On Mon, Feb 15, 2016 at 12:29 PM, Bernd Edlinger
wrote:
> On 15/02/16 08:18, Dmitry Vyukov wrote:
>> llvm tsan tests contain test.h file (probably what's called
>> test_barrier.h in gcc), you can put the macro there. test.h should
>> already be included into all tests.
&
On Mon, Feb 15, 2016 at 11:45 AM, Tom de Vries wrote:
> On 15/02/16 10:07, Bernd Edlinger wrote:
>>
>> On 15/02/16 09:07, Tom de Vries wrote:
>>>>
>>>> >>On 15/02/16 08:24, Dmitry Vyukov wrote:
>>>> >>
>>>> >>I
On Mon, Feb 15, 2016 at 10:07 AM, Bernd Edlinger
wrote:
> On 15/02/16 09:07, Tom de Vries wrote:
>>>On 15/02/16 08:24, Dmitry Vyukov wrote:
>>>
>>>If we are talking about pr 68580, then I would try:
>>>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=685
If we are talking about pr 68580, then I would try:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580#c2
first.
On Mon, Feb 15, 2016 at 8:18 AM, Dmitry Vyukov wrote:
> On Mon, Feb 15, 2016 at 7:00 AM, Tom de Vries wrote:
>> Hi,
>>
>> Occasionally, I've been runni
On Mon, Feb 15, 2016 at 7:00 AM, Tom de Vries wrote:
> Hi,
>
> Occasionally, I've been running into this failure while running the tsan
> testsuite:
> ...
> FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test
> ...
>
> I've also observed a potential similar occurrence here (
> https://gcc.gnu.o
On Mon, Dec 7, 2015 at 4:20 PM, Jakub Jelinek wrote:
> On Mon, Dec 07, 2015 at 04:16:02PM +0100, Dmitry Vyukov wrote:
>> Index: ChangeLog
>> ===
>> --- ChangeLog (revision 231362)
>> +++ ChangeLog (wo
On Mon, Dec 7, 2015 at 3:09 PM, Jakub Jelinek wrote:
> On Sun, Dec 06, 2015 at 09:56:32AM +0100, Dmitry Vyukov wrote:
>
>> --- gcc.dg/sancov/sancov.exp (revision 231328)
>> +++ gcc.dg/sancov/sancov.exp (working copy)
>> @@ -18,6 +18,7 @@
>>
>> load_lib gcc-dg.
On Mon, Dec 7, 2015 at 2:56 PM, Nathan Sidwell wrote:
> On 12/06/15 03:56, Dmitry Vyukov wrote:
>>
>> Hello,
>>
>> Sancov tests submitted in 231296 assume that asan is supported on all
>> platforms.
>> This patch fixes that assumption.
>
>
>&
On Sat, Dec 5, 2015 at 1:54 AM, Nathan Sidwell wrote:
> On 12/04/15 13:28, Dmitry Vyukov wrote:
>>
>> On Fri, Dec 4, 2015 at 6:39 PM, Jakub Jelinek wrote:
>>>
>>> On Fri, Dec 04, 2015 at 06:32:38PM +0100, Dmitry Vyukov wrote:
>>>>
>>>>
@@
+2015-12-06 Dmitry Vyukov
+
+ * gcc.dg/sancov/sancov.exp: Don't run asan tests when asan is not
+ available.
+
2015-12-05 David Edelsohn
* gcc.target/powerpc/recip-sqrtf.c: New test.
Index: gcc.dg/sancov/sanco
On Fri, Dec 4, 2015 at 6:39 PM, Jakub Jelinek wrote:
> On Fri, Dec 04, 2015 at 06:32:38PM +0100, Dmitry Vyukov wrote:
>> +2015-12-04 Dmitry Vyukov
>> +
>> + * sancov.c: New file.
>> + * Makefile.in (OBJS): Add sancov.o.
>> + * invoke.texi (-fsani
's gcov/-fprofile-generate etc.?
>>
>> On Thu, Dec 03, 2015 at 08:17:06PM +0100, Dmitry Vyukov wrote:
>>>
>>> +unsigned sancov_pass (function *fun)
>>
>>
>> Formatting:
>> unsigned
>> sancov_pass (function *fun
ge modes are backed
by sanitizer_common runtime and libFuzzer, which together allow to do
efficient in-process fuzzing.
We don't have plans to port other options at the moment per se.
Though, that's doable and we could sync sanitizer library for runtime
support.
> On Thu, D
On Thu, Dec 3, 2015 at 7:34 PM, Dmitry Vyukov wrote:
> I've attached updated patch (also reuploaded
> https://codereview.appspot.com/280140043).
> Fixed ChangeLog.
> Added invoke.texi.
> Fixed style issues.
>
> The function is defined only in kernel at the moment.
+1,15 @@
+2015-12-03 Dmitry Vyukov
+
+ * sancov.c: New file.
+ * Makefile.in (OBJS): Add sancov.o.
+ * invoke.texi (-fsanitize-coverage=trace-pc): Describe.
+ * passes.def (sancov_pass): Add.
+ * tree-pass.h (sancov_pass): Add.
+ * common.opt (-fsanitize-coverage=trace-pc): Add.
+ * sanitize
On Wed, Dec 2, 2015 at 6:11 PM, Bernd Schmidt wrote:
> On 12/02/2015 05:55 PM, Dmitry Vyukov wrote:
>>
>> Can you point to some concrete coding style violations (besides
>> function comments)?
>>
>> (flag_sanitize &
On Wed, Dec 2, 2015 at 5:47 PM, Bernd Schmidt wrote:
> On 12/02/2015 05:10 PM, Dmitry Vyukov wrote:
>>
>> ping
>
>
> I do not see the original submission in my archives.
That's strange. I don't see it in gcc-patches archives as well.
The original email conta
On Wed, Dec 2, 2015 at 5:10 PM, Dmitry Vyukov wrote:
> ping
>
> Number of bugs found with this coverage in kernel already crossed 40:
> https://github.com/google/syzkaller/wiki/Found-Bugs
>
>
>
>
> On Fri, Nov 27, 2015 at 3:30 PM, Dmitry Vyukov wrote:
>> +syz
ping
Number of bugs found with this coverage in kernel already crossed 40:
https://github.com/google/syzkaller/wiki/Found-Bugs
On Fri, Nov 27, 2015 at 3:30 PM, Dmitry Vyukov wrote:
> +syzkaller group
>
> On Fri, Nov 27, 2015 at 3:28 PM, Dmitry Vyukov wrote:
>> Hello,
>&g
te:
> On 02/09/15 16:01 +0200, Dmitry Vyukov wrote:
>>
>> Added comment to _M_dispose and restored ChangeLog entry.
>> Please take another look.
>
>
> Thanks, this is OK for trunk.
>
> I assume you are covered by the Google company-wide copyright
> assignment,
Added comment to _M_dispose and restored ChangeLog entry.
Please take another look.
On Wed, Sep 2, 2015 at 3:17 PM, Jonathan Wakely wrote:
> On 01/09/15 17:42 +0200, Dmitry Vyukov wrote:
>>
>> On Tue, Sep 1, 2015 at 5:08 PM, Jonathan Wakely
>> wrote:
>>>
>&
On Wed, Sep 2, 2015 at 12:58 PM, Marc Glisse wrote:
> On Tue, 1 Sep 2015, Dmitry Vyukov wrote:
>
>> The refcounted basic_string implementation contains several data races
>> on _M_refcount:
>
>
> There are several bug reports about races in basic_string in bugzilla (
On Tue, Sep 1, 2015 at 5:08 PM, Jonathan Wakely wrote:
> On 01/09/15 16:56 +0200, Dmitry Vyukov wrote:
>>
>> I don't understand how a new gcc may not support __atomic builtins on
>> ints. How it is even possible? That's a portable API provided by
>> recent gc
On Tue, Sep 1, 2015 at 4:27 PM, Jonathan Wakely wrote:
> On 01/09/15 14:51 +0200, Dmitry Vyukov wrote:
>>
>> Hello,
>>
>> The refcounted basic_string implementation contains several data races
>> on _M_refcount:
>> 1. _M_is_leaked loads _M_refcount concur
Hello,
The refcounted basic_string implementation contains several data races
on _M_refcount:
1. _M_is_leaked loads _M_refcount concurrently with mutations of
_M_refcount. This loads needs to be memory_order_relaxed load, as
_M_is_leaked predicate does not change under the feet.
2. _M_is_shared lo
On Sat, Jun 27, 2015 at 7:12 PM, Jakub Jelinek wrote:
> On Sat, Jun 27, 2015 at 04:53:22PM +0200, Dmitry Vyukov wrote:
>> Do you plan to move forward with this patch? Is it waiting to be reviewed?
>> People keep asking about exception support for tsan (I guess it is
>> criti
Hi Jakub,
Do you plan to move forward with this patch? Is it waiting to be reviewed?
People keep asking about exception support for tsan (I guess it is
critical for a significant potion of C++ out there). I am trying to
sketch support in llvm. And I am leaning towards an approach similar
to yours,
OK
On Wed, Mar 11, 2015 at 5:41 PM, Bernd Edlinger
wrote:
> Hi Jakub,
>
>
> with my OPC UA Server, I observe a reproducible crash in
> ScopedReport::AddThread: tctx==NULL
> in "if ((u32)rep_->threads[i]->id == tctx->tid)".
>
> Apparently, Dmitry has already fixed that in the obvious way.
>
> So w
On Thu, Jan 22, 2015 at 5:03 PM, Jakub Jelinek wrote:
> On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote:
>> ping.
>>
>> Forgot to mention, GCC bootstraps and regression testing passed on x86_64.
>
> Well, without a change from upstream to guard the HACKY_CALL and actual tsan
>
On Wed, Jan 21, 2015 at 5:38 PM, Bernd Edlinger
wrote:
> Hi,
>
> On 21 Jan 2015 17:57:10, Dmitry Vyukov wrote:
>> Subject: Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update
>> To: bernd.edlin...@hotmail.de
>> CC: konstantin.s.serebry...@gmail.com; mikest...@comca
ock_ inside of pthread_cond_wait; or
when a thread needs to process signals. But all remaining uses of
sleep are commented.
On Wed, Jan 21, 2015 at 11:58 AM, Dmitry Vyukov wrote:
> On Tue, Jan 20, 2015 at 10:09 AM, Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> On Mon
Well, OK, it is actually not easier to write tests with step function
as compared to barrier.
On Wed, Jan 21, 2015 at 11:58 AM, Dmitry Vyukov wrote:
> On Tue, Jan 20, 2015 at 10:09 AM, Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> On Mon, 19 Jan 2015 18:49:2
On Tue, Jan 20, 2015 at 10:09 AM, Bernd Edlinger
wrote:
>
> Hi,
>
> On Mon, 19 Jan 2015 18:49:21, Konstantin Serebryany wrote:
>>
>> [text-only]
>>
>> On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump wrote:
>>> On Jan 19, 2015, at 12:43 AM, Dmitry Vyuko
On Wed, Jan 21, 2015 at 11:34 AM, Jakub Jelinek wrote:
> On Wed, Jan 21, 2015 at 12:23:34PM +0400, Dmitry Vyukov wrote:
>> Hi Mike,
>>
>> Yes, I can quantify the cost. Is it very high.
>>
>> Here is the patch that I used:
>>
>> --- rtl/tsan_rtl.cc (rev
] DISABLED_BENCH.Mop8Write (5085 ms)
So that's 338% slowdown.
On Mon, Jan 19, 2015 at 6:12 PM, Mike Stump wrote:
> On Jan 19, 2015, at 12:47 AM, Dmitry Vyukov wrote:
>> Long story short. Tsan has a logical data race the core of data race
>> detection algorithm. The race is not a bug, but
Long story short. Tsan has a logical data race the core of data race
detection algorithm. The race is not a bug, but a deliberate design
decision that makes tsan considerably faster. So ironically, if the
race memory accesses happen almost simultaneously, tsan can miss the
race.
Thus we have sleeps
On Fri, Jan 16, 2015 at 8:42 PM, Bernd Edlinger
wrote:
> Hi,
>
> On Fri, 16 Jan 2015 21:25:42, Dmitry Vyukov wrote:
>>
>> This is just a copy from llvm repo, right?
>> Looks good to me.
>>
>
> Thanks.
>
> Yes I found these test case in the llvm tre
This is just a copy from llvm repo, right?
Looks good to me.
On Fri, Jan 16, 2015 at 10:17 AM, Bernd Edlinger
wrote:
> Hi,
>
>
> I think I should ping for this patch now:
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00599.html
>
> note that by mistake the change log referenced sanitizer.c inst
Cool! Thanks.
Gcc is again ahead of clang :)
On Sat, Jan 3, 2015 at 1:11 AM, Jakub Jelinek wrote:
> On Fri, Jan 02, 2015 at 11:01:56PM +0100, Bernd Edlinger wrote:
>> gcc/ChangeLog:
>> 2015-01-02 Bernd Edlinger
>>
>> Instrument bit field and unaligned accesses for TSAN.
>> * sani
Hi,
Sorry for the delay, I was on a vacation. Is here anything to do/review for me?
On Sun, Jan 11, 2015 at 4:15 PM, Bernd Edlinger
wrote:
> Hi,
>
>
>
> On Sun, 4 Jan 2015 14:54:56, Bernd Edlinger wrote:
>>
>> Hi Jakub,
>>
>>
>> I think I have found a reasonable test case, see the attached patc
Cross referenced this patch from
https://code.google.com/p/thread-sanitizer/issues/detail?id=78
On Tue, Dec 16, 2014 at 12:25 PM, Dmitry Vyukov wrote:
> I am not qualified to review the actual code changes, but from the
> description it looks good to me.
>
> It adds a EH frame to ev
I am not qualified to review the actual code changes, but from the
description it looks good to me.
It adds a EH frame to every function, right? In 64-bit mode there is
no runtime penalty, right? Do you have any idea about binary size
increase? Does gcc build in C++ mode nowadays? It can be a good
will wait for Andrey this time
On Thu, Dec 4, 2014 at 10:12 PM, Jakub Jelinek wrote:
> On Thu, Dec 04, 2014 at 11:10:15PM +0400, Dmitry Vyukov wrote:
>> That would be an option too. I don't know whether it is much better or not.
>> Kernel lives without constructors, t
On Wed, Dec 3, 2014 at 9:19 AM, Andrey Ryabinin wrote:
> On 12/02/2014 08:56 PM, Dmitry Vyukov wrote:
>> Hi,
>>
>> The following patch adds support for instrumentation of globals for
>> Linux kernel (-fsanitize=kernel-address). Kernel only supports
>> constructo
On Thu, Dec 4, 2014 at 5:16 PM, Yury Gribov wrote:
> On 12/04/2014 05:04 PM, Dmitry Vyukov wrote:
>>
>> On Thu, Dec 4, 2014 at 4:48 PM, Yury Gribov wrote:
>>>
>>> On 12/04/2014 03:47 PM, Dmitry Vyukov wrote:
>>>>
>>>>
>>>>
On Thu, Dec 4, 2014 at 4:48 PM, Yury Gribov wrote:
> On 12/04/2014 03:47 PM, Dmitry Vyukov wrote:
>>
>> size_in_bytes = -1 instrumentation is too slow to be the default in
>> kernel.
>>
>> If we want to pursue this, I propose a different scheme.
>> Handle
+address-sanitizer
Please don't hurry with it.
Do you have any numbers on how frequent are unaligned accesses in
kernel? Is it worth addressing at this cost?
size_in_bytes = -1 instrumentation is too slow to be the default in kernel.
If we want to pursue this, I propose a different scheme.
Hand
On Tue, Dec 2, 2014 at 9:17 PM, Jakub Jelinek wrote:
> On Tue, Dec 02, 2014 at 10:12:30PM +0400, Dmitry Vyukov wrote:
>> > Shall we backport it to 4.9 branch too?
>>
>> If it's doable, it would be nice. Thanks.
>
> Bet the same patch will just apply there.
Do I
On Tue, Dec 2, 2014 at 9:04 PM, Jakub Jelinek wrote:
> On Tue, Dec 02, 2014 at 09:56:36PM +0400, Dmitry Vyukov wrote:
>> --- gcc/ChangeLog (revision 218280)
>> +++ gcc/ChangeLog (working copy)
>> @@ -1,3 +1,8 @@
>> +2014-12-02 Dmitry Vyukov
>> +
>> + *
===
--- gcc/ChangeLog (revision 218280)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2014-12-02 Dmitry Vyukov
+
+ * asan.c: (asan_finish_file): Use default priority for constructors
+ in kernel mode.
+
2014-12-02 Ulrich Weigand
PR target
Looks good to me.
Thanks!
On Wed, Nov 26, 2014 at 10:43 PM, Jakub Jelinek wrote:
> On Fri, Nov 21, 2014 at 04:20:44PM +0400, Dmitry Vyukov wrote:
>> Yes, I think it's the way to go.
>> I've just committed the following revision to clang that removes -pie
>> wh
On Thu, Nov 13, 2014 at 12:16 PM, Jakub Jelinek wrote:
> On Wed, Nov 12, 2014 at 05:35:48PM -0800, Konstantin Serebryany wrote:
>> Here is one more merge of libsanitizer (last one was in Sept).
>>
>> Tested on x86_64 Ubuntu 14.04 like this:
>> rm -rf */{*/,}libsanitizer && make -j 50
>> make -j 40
On Fri, Oct 24, 2014 at 1:59 PM, Yury Gribov wrote:
> On 10/24/2014 01:44 PM, Dmitry Vyukov wrote:
>>
>> On Fri, Oct 24, 2014 at 12:28 PM, Yury Gribov
>> wrote:
>>>
>>> On 10/23/2014 03:10 PM, Andrey Ryabinin wrote:
>>>>
>>>>
>>
On Fri, Oct 24, 2014 at 1:50 PM, Jakub Jelinek wrote:
> On Fri, Oct 24, 2014 at 01:44:27PM +0400, Dmitry Vyukov wrote:
>> I am somewhat lost in this thread and probably missing something.
>> But why do we need __asan_load (which is not noabort) at all? Outline
>> instrumenta
On Fri, Oct 24, 2014 at 12:28 PM, Yury Gribov wrote:
> On 10/23/2014 03:10 PM, Andrey Ryabinin wrote:
>>
>> On 10/23/2014 02:38 PM, Jakub Jelinek wrote:
>>>
>>> On Thu, Oct 23, 2014 at 02:33:42PM +0400, Yury Gribov wrote:
Actually this is a historical artifact. If inlining proves to be
Looks good to me
On Fri, Oct 3, 2014 at 5:07 PM, Yury Gribov wrote:
> Hi all,
>
> This patch disables generation of asan_init calls for KASan as discussed in
> https://lkml.org/lkml/2014/9/26/711
>
> Bootstrapped and regtested no x64. Ok to commit?
>
> -Y
>
> commit 91c015e54687666f4abf6745f33c2e
On Fri, Sep 5, 2014 at 12:12 PM, Yury Gribov wrote:
> On 09/05/2014 11:32 AM, Dmitry Vyukov wrote:
>>
>> Can we do it w/o doubling number of runtime entry points?
>
>
> I didn't find a good way to achieve this. See, normal asan reporting
> functions
> ha
On Fri, Sep 5, 2014 at 10:54 AM, Yury Gribov wrote:
> Hi all,
>
> This patch enables -fsanitize-recover for KASan by default. This causes
> KASan to continue execution after error in case of inline instrumentation.
> This feature is needed because
> - reports during early bootstrap won't even be p
On Fri, Aug 8, 2014 at 2:37 PM, Jakub Jelinek wrote:
> On Fri, Aug 08, 2014 at 02:26:25PM +0400, Yury Gribov wrote:
>> I have been working on Asan global optimization pass lately. The goal is to
>> remove redundant Asan checks from sanitized code. This should hopefully
>> reduce Asan's speed/size
On Fri, Jul 18, 2014 at 4:26 PM, Jakub Jelinek wrote:
> On Fri, Jul 18, 2014 at 03:40:15PM +0400, Yury Gribov wrote:
>> This tiny patch adds support for KernelASan. KASan brings Asan error
>> detection capabilities to Linux kernel
>> (https://code.google.com/p/address-sanitizer/wiki/AddressSanitiz
On Fri, Jul 18, 2014 at 3:40 PM, Yury Gribov wrote:
> Hi all,
>
> This tiny patch adds support for KernelASan. KASan brings Asan error
> detection capabilities to Linux kernel
> (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel).
>
> KASan works similar to normal userspac
On Wed, May 28, 2014 at 8:36 AM, Konstantin Serebryany
wrote:
> Dmitry,
> You've introduced atomic_uint64_t stats_[AllocatorStatCount]; in
> http://llvm.org/viewvc/llvm-project?view=revision&revision=173332
> Do you mind to change it to atomic_uintptr_t?
> There is of course a chance of overflow
On Tue, May 27, 2014 at 9:39 PM, Yuri Gribov wrote:
>> Asan and kasan are very different, so it would be good to separate
>> them straight away.
>
> Do you mean separation of interfaces (i.e. have -fsanitize=address and
> -fsanitize=kernel-address but use same code in GCC to compile both
> maybe w
On Tue, May 27, 2014 at 9:43 AM, Konstantin Serebryany
wrote:
> On Tue, May 27, 2014 at 9:40 AM, Yury Gribov wrote:
>>> - using instrumentation via calls adds extra 1.5x-2.x slowdown
>>
>> On x64.
>
> Interesting. can you share your ARM numbers?
>
>>
>>
>>> - it would be nice to have the name pre
On Fri, Dec 6, 2013 at 12:25 PM, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 12:19:45PM +0400, Dmitry Vyukov wrote:
>> > And the reason why check-g++ tsan.exp fails even with this patch is
>> > that apparently tsan doesn't try to demangle the symbol names, so we get
&
On Fri, Dec 6, 2013 at 11:50 AM, Jakub Jelinek wrote:
> Hi!
>
> With the new tsan tests, I've noticed that libbacktrace symbolization
> doesn't work when the binary is a PIE.
> The problem is that in that case we obviously can't use base_address
> of 0, the PIE typically will not have 0 bias, that
On Tue, Feb 12, 2013 at 3:16 AM, Mike Stump wrote:
> On Feb 11, 2013, at 7:55 AM, Jack Howarth wrote:
>> Iain Sandoe discovered that on intel darwin9, the asan testsuite suffers
>> hundreds of
>> failures due to the absence of dispatch calls (Grand Central Dispatch) prior
>> to darwin10.
>> Th
LGTM
On Thu, Jan 31, 2013 at 8:54 PM, VandeVondele Joost
wrote:
> The updated changelog entry is below, but somebody with write access should
> do the commit, please.
>
> 2013-01-31 Dmitry Vyukov
> Joost VandeVondele
>
> PR libgomp/55561
>
On Thu, Jan 24, 2013 at 9:29 PM, Torvald Riegel wrote:
> On Mon, 2012-12-17 at 13:52 +0400, Dmitry Vyukov wrote:
>> resend in plain text
>>
>> On Mon, Dec 17, 2012 at 1:50 PM, Dmitry Vyukov wrote:
>> >
>> > On Fri, Dec 14, 2012 at 5:43 PM, Torvald Riegel
Rubber stamp LGTM
On Wed, Jan 23, 2013 at 2:31 PM, Konstantin Serebryany
wrote:
> Hi,
>
> The attached patch is the libsanitizer merge from upstream r173241.
>
> Lots of changes. Among other things:
> - slow CFI-based unwinder is on by default for fatal errors
> (fast_unwind_on_fatal=0, Linux-o
On Thu, Jan 10, 2013 at 11:01 AM, Konstantin Serebryany
wrote:
> Hi,
>
> The attached patch is the libsanitizer merge from upstream r171973.
>
> Lots of changes. Among other things:
> - slow CFI-based unwinder (off by default for now)
> - more interceptors in asan (read, pread, etc)
> - prec
resend in plain text
On Mon, Dec 17, 2012 at 1:50 PM, Dmitry Vyukov wrote:
>
> On Fri, Dec 14, 2012 at 5:43 PM, Torvald Riegel wrote:
> > On Thu, 2012-12-13 at 10:02 +0100, Jakub Jelinek wrote:
> >> On Thu, Dec 13, 2012 at 10:38:13AM +0400, Dmitry Vyukov wrote:
> >>
On Thu, Dec 13, 2012 at 1:02 PM, Jakub Jelinek 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 correct
On Thu, Dec 13, 2012 at 1:58 AM, Richard Henderson wrote:
> On 12/12/2012 11:50 AM, Jakub Jelinek wrote:
>> 2012-12-12 Jakub Jelinek
>>
>> PR sanitizer/55508
>> * builtin-attrs.def (ATTR_TMPURE_NOTHROW_LEAF_LIST,
>> ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST): New.
>> * asan
On Wed, Dec 12, 2012 at 11:50 PM, Jakub Jelinek wrote:
> Hi!
>
> 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
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_interface_atomic.cc?view=diff&r1=169378&r2=169379&pathrev=169379
We will integrate it later.
On Wed, Dec 5, 2012 at 5:03 PM, Dmitry Vyukov wrote:
> Yeah, but then there will be all that additional __s
4PM +0400, Dmitry Vyukov wrote:
>> On Wed, Dec 5, 2012 at 4:42 PM, Jakub Jelinek wrote:
>> > On Wed, Dec 05, 2012 at 03:13:20PM +0400, Dmitry Vyukov wrote:
>> >> I hope I addressed all your comments in this revision.
>> >> I've fixed nand atomic operation
On Wed, Dec 5, 2012 at 4:42 PM, Jakub Jelinek wrote:
> On Wed, Dec 05, 2012 at 03:13:20PM +0400, Dmitry Vyukov wrote:
>> I hope I addressed all your comments in this revision.
>> I've fixed nand atomic operation, made atomic operations atomic again
>> and added visibil
Jakub,
I hope I addressed all your comments in this revision.
I've fixed nand atomic operation, made atomic operations atomic again
and added visibility attribute to interface functions.
On Wed, Dec 5, 2012 at 3:11 PM, Dmitry Vyukov wrote:
> LGTM
>
> On Wed, Dec 5, 2012 at 2:59
LGTM
On Wed, Dec 5, 2012 at 2:59 PM, Konstantin Serebryany
wrote:
> Hi,
>
> The attached patch is the libsanitizer mege from upstream r169371.
> Automatically generated by libsanitizer/merge.sh
> Tested with
> rm -rf */{*/,}libsanitizer \
> && make -j 50 \
> && make -C gcc check-g{cc,++}
> RU
1 - 100 of 123 matches
Mail list logo
