+dnovillo, davidxl
Any suggestions?
On Wed, Oct 2, 2013 at 12:54 PM, Konstantin Serebryany
wrote:
>
>
>
>
> On Wed, Oct 2, 2013 at 12:51 PM, Konstantin Serebryany
> wrote:
>> Hi,
>>
>> I'd like to start a review for libsanitizer merge from upstream.
&
Thanks!
(I still need more suggestions/review :)
On Mon, Oct 14, 2013 at 3:48 PM, Marek Polacek wrote:
>> >> I tested this change like this on x86_64 Linux Ubuntu 12.04:
>> >> rm -rf */{*/,}libsanitizer && make -j 50 && make -C gcc
>> >> check-g{cc,++} RUNTESTFLAGS='--target_board=unix\{-m32,-m
On Tue, Oct 29, 2013 at 6:52 AM, Jakub Jelinek wrote:
> On Tue, Oct 29, 2013 at 06:49:30AM -0700, Konstantin Serebryany wrote:
>> Thanks!
>> (At this time I will be slow with response due to travel)
>
> BTW, don't have compiled clang/llvm pre-3.4 around to look at, for
san/deep-thread-stack-1.C -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (test for excess errors)
W/o your change they pass.
Could you please remind me how to debug this (i.e. how to run the
exact test commands manually)?
Thanks!
--kcc
On Tue, Oct 29, 2013 at 6:49 AM, Konstantin Serebryan
c-c++-common/asan/stack-overflow-1.c:13:
undefined reference to `.LASANPC0.2585'
collect2: error: ld returned 1 exit status
Looks like this patch is not friendly to -flto
--kcc
On Tue, Oct 29, 2013 at 4:54 PM, Konstantin Serebryany
wrote:
> Jakub,
>
> Your patch seems to do what it sho
PM -0700, Konstantin Serebryany wrote:
>> 2013-10-XX Kostya Serebryany
>
> It is November now ;)
>
> Looks good to me, except for a few ChangeLog issues:
>
>> Update to match the changed asan API.
>> * asan.c:
>> (asan_function_start
13 at 04:13:05PM -0700, Konstantin Serebryany wrote:
>> Jukub,
>>
>> This works!
>> New patch attached.
>
> Konstantin,
>This patch, when applied on top of r204305, bootstraps fine on
> x86_64-apple-darwin12 but
> produces a lot of regressions w
On Mon, Nov 4, 2013 at 8:46 AM, Jack Howarth wrote:
> On Mon, Nov 04, 2013 at 06:47:13AM -0800, Konstantin Serebryany wrote:
>> +glider, our Mac expert.
>>
>> Hi Jack,
>>
>> This patch has not been tested on Mac and we generally do not claim
>> that gcc-asan
Hi Peter.
Does this also mean that asan in llvm trunk is broken for Power?
We'll need to fix it there too (or, in fact, first).
--kcc
On Mon, Nov 4, 2013 at 4:33 PM, Peter Bergner wrote:
> On Mon, 2013-11-04 at 06:47 -0800, Konstantin Serebryany wrote:
>> This patch has not been
Is this the same failure or different?
On Mon, Nov 4, 2013 at 9:49 PM, H.J. Lu wrote:
> It also breaks x32 build.
>
>
> On Mon, Nov 4, 2013 at 5:48 PM, Konstantin Serebryany
> wrote:
>> Hi Peter.
>> Does this also mean that asan in llvm trunk is broken for Power?
&g
-ppc64-linux2/builds/8086
>
> This build completed about two hours ago.
>
> Hope this helps,
> Bill
>
> On Mon, 2013-11-04 at 20:02 -0600, Peter Bergner wrote:
>> On Mon, 2013-11-04 at 17:48 -0800, Konstantin Serebryany wrote:
>> > Hi Peter.
>> > Does this
I'd be glad to have tsan tests in GCC.
At the very least we need to have a couple of sanity tests to make
sure tsan links and finds a trivial race.
The only mode in which my team can truly support tsan tests is when
they are verbatim copies of the upstream tests
and they are merged together with th
On Mon, Dec 2, 2013 at 6:41 PM, Marek Polacek wrote:
> On Mon, Dec 02, 2013 at 02:41:05PM +0100, Marek Polacek wrote:
>> On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
>> > This change breaks one ubsan test:
>> > make check -C gcc RUNTESTFLAGS
On Mon, Dec 2, 2013 at 4:49 PM, Uros Bizjak wrote:
> Hello!
>
>>> Does it support using libbacktrace in GCC?
>>
>> Not on it's own, but the support in the upstream maintained files
>> is there, so hopefully it will be just a matter of follow-up patch
>> with configury/Makefile etc. stuff, I'll wor
On Mon, Dec 2, 2013 at 5:26 PM, Uros Bizjak wrote:
> On Mon, Dec 2, 2013 at 5:12 PM, Konstantin Serebryany
> wrote:
>
>>>>> Does it support using libbacktrace in GCC?
>>>>
>>>> Not on it's own, but the support in the upstream maintained files
On Mon, Dec 2, 2013 at 5:44 PM, Jakub Jelinek wrote:
> On Mon, Dec 02, 2013 at 05:26:45PM +0100, Uros Bizjak wrote:
>> No, so your patch doesn't regress anything. I can configure with
>> --disable-libsanitizer to skip build of libsanitizer, although it
>> would be nice to support RHEL5 derived lon
On Tue, Dec 3, 2013 at 2:32 AM, Jakub Jelinek wrote:
> On Mon, Dec 02, 2013 at 05:59:53PM +0100, Konstantin Serebryany wrote:
>> >> with #if LINUX_VERSION_CODE >= 132640
>> Good idea, let me try that.
>
> Had a quick look at this on RHEL 5.
> Following patch
On Tue, Dec 3, 2013 at 3:50 PM, Jakub Jelinek wrote:
> On Mon, Dec 02, 2013 at 05:43:17PM +0100, Konstantin Serebryany wrote:
>> > No, so your patch doesn't regress anything. I can configure with
>> > --disable-libsanitizer to skip build of libsanitizer, although it
>
>>>
>>> This won't happen any time soon, right?
>>> I'd like to ask glibc for many other things, not just this, but the
>>> latency
>>> of the glibc changes propagating to users is too low, so we don't
>>> bother (although we should)
>>> E.g. we've been hit by the ugly
>>> pthread_getattr_np/pthrea
On Tue, Dec 3, 2013 at 5:42 PM, Jeff Law wrote:
> On 12/03/13 08:47, Jakub Jelinek wrote:
>>
>> On Tue, Dec 03, 2013 at 07:18:14PM +0400, Konstantin Serebryany wrote:
>>>>>>
>>>>>> No, so your patch doesn't regress anything. I can confi
On Mon, Dec 2, 2013 at 11:32 PM, Jakub Jelinek wrote:
> On Mon, Dec 02, 2013 at 05:59:53PM +0100, Konstantin Serebryany wrote:
>> >> with #if LINUX_VERSION_CODE >= 132640
>> Good idea, let me try that.
>
> Had a quick look at this on RHEL 5.
> Following patch
> Of course various parties care about that. But that doesn't necessarily
> imply they can or want to run buildbots for a different compiler they don't
> care about, there are e.g. security implications to that, resources etc.
This brings us back to the initial issue: the way asan&co are develope
On Wed, Dec 4, 2013 at 5:02 PM, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 04:49:22PM +0400, Konstantin Serebryany wrote:
>> I would start from kernel version and glibc version, this should cover
>> the majority of use cases.
>
> Well, for the kernel headers what we perha
[new subject. was: libsanitizer merge from upstream r196090]
>> .cfi is used only in tsan sources now, and tsan is not supported
>> anywhere but x86_64
>
> But the .cfi_* issue is platform independent. Whether the compiler
> decides to emit them or not depends on how it was configured, on assembl
On Wed, Dec 4, 2013 at 5:44 PM, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 05:28:40PM +0400, Konstantin Serebryany wrote:
>> > Well, for the kernel headers what we perhaps can do is just add
>> > libsanitizer/include/linux/ tree that will be maintained by GCC and will
&g
On Wed, Dec 4, 2013 at 6:16 PM, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 06:09:56PM +0400, Konstantin Serebryany wrote:
>> This is a maintenance problem because we can not test if we broke
>> something during development.
>> e.g. clang doesn't seem to support -fno-
Committed upstream:
http://llvm.org/viewvc/llvm-project?view=revision&revision=196480
On Thu, Dec 5, 2013 at 11:39 AM, Konstantin Serebryany
wrote:
> On Wed, Dec 4, 2013 at 6:16 PM, Jakub Jelinek wrote:
>> On Wed, Dec 04, 2013 at 06:09:56PM +0400, Konstantin Serebryany wrote:
On Wed, Dec 4, 2013 at 8:58 PM, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 08:47:41AM -0800, H.J. Lu wrote:
>> > I believe this is a case where the GCC project gets more benefit from
>> > libsanitizer than libsanitizer gets from being part of the GCC
>> > project. We should work with the libs
my 2c: running all upstream tsan tests (ninja check-tsan) takes 10
seconds on my (beefy) machine and requires rather little memory.
Of course, you need lots of *virtual* memory.
On Thu, Dec 5, 2013 at 12:07 PM, Jakub Jelinek wrote:
> On Thu, Dec 05, 2013 at 10:12:36AM +0400, max wrote:
>> Hello,
On Thu, Dec 5, 2013 at 12:18 PM, Jakub Jelinek wrote:
> On Thu, Dec 05, 2013 at 11:51:12AM +0400, Konstantin Serebryany wrote:
>> Committed upstream:
>> http://llvm.org/viewvc/llvm-project?view=revision&revision=196480
>
> LGTM, can we commit it after the merge you hav
Another libsanitizer merge from upstream, r196489
(Quick follow up after the r196090 merge)
Fixes (hopefully) .cfi and ppc32 support.
Tested on x86_64 Linux Ubuntu 12.04 box:
make -j 40 -C gcc check-g{cc,++}
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp'
The ubsan testing fails, but th
>> On Thu, Dec 05, 2013 at 02:06:52PM +0400, Konstantin Serebryany wrote:
>>> Another libsanitizer merge from upstream, r196489
>>> (Quick follow up after the r196090 merge)
>>
>> That commit breaks the build with:
>>
>> In file included from ../../.
On Thu, Dec 5, 2013 at 1:05 AM, Jeff Law wrote:
> On 12/03/13 22:08, Konstantin Serebryany wrote:
>>
>> We need
>> a) patches that we can review and apply to the llvm repository (w/o
>> breaking the modern systems, of course)
>> b) a buildbot that would run 24/7
On Thu, Dec 5, 2013 at 4:22 PM, Konstantin Serebryany
wrote:
> On Thu, Dec 5, 2013 at 1:05 AM, Jeff Law wrote:
>> On 12/03/13 22:08, Konstantin Serebryany wrote:
>>>
>>> We need
>>> a) patches that we can review and apply to the llvm repository (w/o
>&g
> The kernel and glibc check should be done at the toplevel.
> So what are the minimum kernel and glibc we want to
> support?
For us, the versions we want to support are those that have green
upstream buildbots and someone to keep them green.
It's hard or impossible to set a more precise combinati
On Thu, Dec 5, 2013 at 4:47 PM, H.J. Lu wrote:
> On Thu, Dec 5, 2013 at 3:18 AM, Konstantin Serebryany
> wrote:
>> On Thu, Dec 5, 2013 at 3:06 PM, Дмитрий Дьяченко wrote:
>>> clang' build is broken for me the same way
>>
>> Should be fixed now (only c
M, H.J. Lu wrote:
> On Thu, Dec 5, 2013 at 4:59 AM, Konstantin Serebryany
> wrote:
>> On Thu, Dec 5, 2013 at 4:47 PM, H.J. Lu wrote:
>>>
>>> There are at least 2 fallouts:
>>>
>>> 1. -mx32 is broken.
>>
>> Please send a patch to the llv
On Fri, Dec 6, 2013 at 3:28 PM, Yury Gribov wrote:
> Hi all,
>
> GCC version of Asan currently lacks options for detailed control over code
> instrumentation. These are not usually necessary but for embedded systems
> with scarce system resources Asan memory overhead of 2x-3x may often be
> unacce
es you get just 1/3 of instrumentation
and slowdown.
Of course, you also get a smaller amount of bugs.
>
> -Y
>
> ---
> From: Yury Gribov
> Sent: Friday, December 06, 2013 3:55PM
> To: Konstantin Serebryany
> Cc: GCC P
On Fri, Dec 6, 2013 at 4:09 PM, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 03:28:50PM +0400, Yury Gribov wrote:
>> Hi all,
>>
>> GCC version of Asan currently lacks options for detailed control
>> over code instrumentation. These are not usually necessary but for
>> embedded systems with scarc
On Fri, Dec 6, 2013 at 4:39 PM, Yury Gribov wrote:
> Konstantin wrote:
>
>> Jakub wrote:
>>> I'm strongly against the blacklist,
>> I don't like it either. We were forced to implement it by reality.
>> ...
>
>> imagine third-party code which you can build but can not change
>
> Same situation here
On Fri, Dec 6, 2013 at 5:10 PM, Yury Gribov wrote:
> Konstantin wrote:
>> Can you have a target specific config for the particular target
>> that will have its own shadow offset & scale?
>
> Yes, we have this but I don't see how this can help with code
> instrumentation overheads.
My comment about
On Tue, Dec 10, 2013 at 12:10 PM, Jakub Jelinek wrote:
> On Tue, Dec 10, 2013 at 12:06:55PM +0400, Yury Gribov wrote:
>> > I'm strongly against the blacklist,
>> > that is not the way things are done in GCC,
>> > you have corresponding attribute to mark functions
>> > you don't want to instrument,
>
> Agreed. I guess our main question is whether such mechanism is really needed
> by developers.
We use the blacklist:
- with asan init-order-checker to disable checking some specific
globals by their type name ("bening" true positive)
- with msan to suppress true benign reports from zlib's defla
What's wrong with C++? :)
Upstream we have 16 .c tests and 106 .cc tests in
compiler-rt/lib/tsan/lit_tests.
We typically prefer .cc because imo C++ is a better language (even
when using what looks like the C subset).
But we need some .c tests to make sure that tsan still works w/o C++ run-time.
-
On Wed, Dec 11, 2013 at 3:27 PM, Jakub Jelinek wrote:
> On Wed, Dec 11, 2013 at 03:21:32PM +0400, Konstantin Serebryany wrote:
>> What's wrong with C++? :)
>> Upstream we have 16 .c tests and 106 .cc tests in
>> compiler-rt/lib/tsan/lit_tests.
>> We typically
Hi,
Please review a small patch (backport from upstream) for libsanitizer.
We are having difficulties on our side and (likely) won't make a full
libsanitizer merge until early Jan.
Index: libsanitizer/ChangeLog
===
--- libsanitizer/C
On Tue, Dec 10, 2013 at 3:38 PM, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 06:40:52AM -0800, Ian Lance Taylor wrote:
>> There was a recent buggy patch to the demangler that added calls to
>> malloc and realloc (2013-10-25 Gary Benson ).
>> That patch must be fixed or reverted before the 4.9 r
On Thu, Jan 9, 2014 at 5:57 PM, Jakub Jelinek wrote:
> On Thu, Jan 09, 2014 at 05:51:05PM +0400, Konstantin Serebryany wrote:
>> On Tue, Dec 10, 2013 at 3:38 PM, Jakub Jelinek wrote:
>> > On Fri, Dec 06, 2013 at 06:40:52AM -0800, Ian Lance Taylor wrote:
>> >> The
I've started a separate topic about flaky tsan tests here:
https://groups.google.com/forum/#!topic/thread-sanitizer/KIok3F_b1oI
--kcc
On Fri, Jan 10, 2014 at 7:20 PM, Jakub Jelinek wrote:
> On Fri, Jan 10, 2014 at 03:50:33PM +0400, Maxim Ostapenko wrote:
>> On Fri, Jan 10, 2014 at 10:39 AM, Jaku
Indeed, thanks for working on this.
We've been wanting such optimization phase from day one, but never got
to implementing it (except for a few simple ones).
https://code.google.com/p/address-sanitizer/wiki/CompileTimeOptimizations
There have been several attempts outside of our team to do such
opt
On Thu, Aug 14, 2014 at 11:55 PM, Yuri Gribov wrote:
> On Thu, Aug 14, 2014 at 8:53 PM, Konstantin Serebryany
> wrote:
>> In order for your work to be generally useful, I'd ask several things:
>> - Update
>> https://code.google.com/p/address-sanitizer/wiki/Com
On Mon, Aug 18, 2014 at 1:05 PM, Yuri Gribov wrote:
> On Fri, Aug 15, 2014 at 10:34 PM, Konstantin Serebryany
> wrote:
>> If this is -O1 or higher, then most (but not all) of your cases
>> *should* be optimized by the compiler before asan kicks in.
>
> You mean hoist
.
int bar();
int foo(unsigned i) {
int a[3] = {bar(), bar(), bar()};
return a[i % 3];
}
--kcc
On Tue, Aug 19, 2014 at 4:42 PM, Konstantin Serebryany
wrote:
> On Mon, Aug 18, 2014 at 1:05 PM, Yuri Gribov wrote:
>> On Fri, Aug 15, 2014 at 10:34 PM, Konstantin Serebryany
>> wrote:
[replying text only]
Hi Chen,
as per https://code.google.com/p/address-sanitizer/wiki/HowToContribute
all changes to libsanitizer, even such simple ones,
have to go through the LLVM tree first.
But, what makes you think there is a bug here?
The comment in sanitizer_common/sanitizer_common.h says:
On Thu, Nov 14, 2013 at 7:33 PM, Jakub Jelinek wrote:
> On Tue, Oct 29, 2013 at 07:05:49AM -0700, Konstantin Serebryany wrote:
>> The calls are emitted by default, but the __asan_stack_malloc call is
>> done under a run-time flag
>> __asan_option_detect_stack_use_after_retu
On Thu, Nov 14, 2013 at 10:09 PM, Jakub Jelinek wrote:
> On Thu, Nov 14, 2013 at 07:08:17PM +0100, Jakub Jelinek wrote:
>> On Thu, Nov 14, 2013 at 09:56:36PM +0400, Konstantin Serebryany wrote:
>> > I thought about alignment but did not reflect it anywhere in the
>> > i
On Fri, Nov 15, 2013 at 2:10 PM, Jakub Jelinek wrote:
> On Fri, Nov 15, 2013 at 12:06:25PM +0400, Konstantin Serebryany wrote:
>> On Thu, Nov 14, 2013 at 10:09 PM, Jakub Jelinek wrote:
>> > On Thu, Nov 14, 2013 at 07:08:17PM +0100, Jakub Jelinek wrote:
>> >> On T
On Fri, Nov 15, 2013 at 6:33 PM, Jakub Jelinek wrote:
> On Fri, Nov 15, 2013 at 06:12:07PM +0400, Konstantin Serebryany wrote:
>> I afraid it actually wants the header (magic, descr, pc) to be in the
>> first 3 words in the
>> memory returned by __asan_stack_
On Fri, Nov 15, 2013 at 7:18 PM, Jakub Jelinek wrote:
> On Fri, Nov 15, 2013 at 06:46:25PM +0400, Konstantin Serebryany wrote:
>> On Fri, Nov 15, 2013 at 6:33 PM, Jakub Jelinek wrote:
>> > On Fri, Nov 15, 2013 at 06:12:07PM +0400, Konstantin Serebryany wrote:
>> >>
+samsonov, who wrote the clang part
Do you plan to add tests?
We have four lit-style tests for this (Alexey, that's all, right?):
init-order-atexit.cc
init-order-dlopen.cc
init-order-pthread-create.cc
Linux/initialization-bug-any-order.cc
I think we need at least the basic one in gcc
(Linux/initi
On Fri, Nov 15, 2013 at 10:40 PM, Jakub Jelinek wrote:
> On Fri, Nov 15, 2013 at 10:34:28PM +0400, Konstantin Serebryany wrote:
>> +samsonov, who wrote the clang part
>>
>> Do you plan to add tests?
>
> Eventually yes, but likely only in stage3, there is only limited ti
On Fri, Nov 15, 2013 at 10:46 PM, Jakub Jelinek wrote:
> On Fri, Nov 15, 2013 at 10:34:28PM +0400, Konstantin Serebryany wrote:
>> +samsonov, who wrote the clang part
>>
>> Do you plan to add tests?
>
> OT, what is the -fsanitize=address,use-after-scope doing? Tried t
On Fri, Nov 15, 2013 at 10:36 PM, Jakub Jelinek wrote:
> On Fri, Nov 15, 2013 at 10:17:49PM +0400, Konstantin Serebryany wrote:
>> >> Why can't we create the redzone of max(32, alignment) bytes?
>> >
>> > Because it is it is expensive, consider say a 2048 byt
Dave,
Do you want the asan/asan_linux.cc (# elif defined(__hppa__)) part to
be in the llvm tree?
--kcc
On Sat, Nov 16, 2013 at 3:55 AM, John David Anglin wrote:
> On 15-Nov-13, at 9:51 AM, Jakub Jelinek wrote:
>
>> On Fri, Nov 15, 2013 at 08:16:47AM -0600, Peter Bergner wrote:
>>>
>>> On Wed, 2
[I beg my pardon if this has already been discussed here]
Does libbacktrace call any functions we intercept (malloc, memset,
memcpy, strlen, etc)?
If so, they will have to be un-intercepted there.
Our hermetic llvm-symbolizer took as so much work for a reason. :(
And doing this work for libbacktrac
an than in asan.
Evgeniy, Dmitry, do you remember any details?
--kcc
On Fri, Nov 22, 2013 at 10:57 PM, Jakub Jelinek wrote:
> On Fri, Nov 22, 2013 at 10:40:00PM +0400, Konstantin Serebryany wrote:
>> [I beg my pardon if this has already been discussed here]
>> Does libbacktr
I am not sure about the lsan part. Sergey?
The rest looks good.
On Sun, Nov 24, 2013 at 8:44 PM, Tobias Burnus wrote:
> As the subject says.
>
> OK for the trunk?
>
> Tobias
Besides all changes to .cc/.h files in libsanitizer should go thorough
the upstream repo first
and I generally dislike the change in
libsanitizer/sanitizer_common/sanitizer_symbolizer_posix_libcdep.cc,
we'll need to find another solution (using libbacktrace could be one;
I am not so enthusiastic ab
On Sat, May 31, 2014 at 11:53 PM, Peter Bergner wrote:
> On Fri, 2014-05-30 at 15:49 +0200, Jakub Jelinek wrote:
>> On Fri, May 30, 2014 at 08:09:22AM -0500, Peter Bergner wrote:
>> > On Thu, 2014-05-29 at 14:07 -0500, Peter Bergner wrote:
>> > > On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge
Committed as r210012, please don't forget to add llvm-commits to CC
next time (I did not see the message)
Thanks!
On Mon, Jun 2, 2014 at 9:57 AM, Yury Gribov wrote:
>>> There was some discussion on what to do, but has there been a decision on
>>> how to fix this yet? Or is it fixed upstream and
On Thu, May 29, 2014 at 6:29 PM, Jonathan Wakely wrote:
> On 26/05/14 19:19 +0400, Konstantin Serebryany wrote:
>>>
>>> It does look useful but I'm concerned about a proliferation of
>>> container checks, we already have the libstdc++ Debug Mode
>>> and
On Tue, Jun 3, 2014 at 1:33 PM, Yury Gribov wrote:
>> Any reason why the BUILT_IN_* names so differ from the actual function
>> names? I.e. why not use BUILT_IN_ASAN_{LOAD,STORE}{1,2,4,8,16,N}
>> (no underscore before N, no CHECK_)?
>
>
> Makes sense.
>
>> Wouldn't it be better to do
>> ...
>>
>>
On Wed, Jun 11, 2014 at 2:28 PM, Paolo Carlini wrote:
> Hi,
>
> On 05/22/2014 09:02 PM, Jakub Jelinek wrote:
>>
>> In file included from
>> ../../../../trunk/libsanitizer/asan/asan_interceptors.cc:147:0:
>>
>> ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:
>> In
Hi Rainer,
All contributions to libsanitizer should go via LLVM repository.
See https://code.google.com/p/address-sanitizer/wiki/HowToContribute
The smaller the patches the faster they will come through.
If you can set up a public build bot it will *immensely* simplify many things.
(see more below
On Fri, Jul 4, 2014 at 4:38 PM, Rainer Orth
wrote:
> Hi Konstantin,
>
>> All contributions to libsanitizer should go via LLVM repository.
>> See https://code.google.com/p/address-sanitizer/wiki/HowToContribute
>> The smaller the patches the faster they will come through.
>
> ok. I'll see how to
On Thu, Nov 13, 2014 at 1:16 AM, 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
4, Konstantin Serebryany
> wrote:
>> On Thu, Nov 13, 2014 at 1:16 AM, 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).
>>>>
&g
I am not sure I understand the problem,
but whatever the problem is I am against using -std=gnu++ as this will
be a different flag combination from what we have upstream.
On Fri, Nov 14, 2014 at 8:50 AM, Konstantin Serebryany
wrote:
> Let's continue the discussion there, we can do anoth
+eugenis (what kind of testing on ARM are we doing upstream?)
On Fri, Nov 14, 2014 at 7:44 AM, Christophe Lyon
wrote:
> On 14 November 2014 11:38, Christophe Lyon wrote:
>> On 13 November 2014 21:44, Konstantin Serebryany
>> wrote:
>>> On Thu, Nov 13, 2014 at 1:16
+gcc-patches
On Fri, Nov 14, 2014 at 11:26 AM, Konstantin Serebryany
wrote:
> I am opposed to this change.
> Upstream code builds with -std=c++11.
> Building this code here with another set of options is a time bomb.
>
> On Fri, Nov 14, 2014 at 6:23 AM, wrote:
>> Author:
sources in GCC is potentially
leading to large delays in the merge process:
imagine that some of the code upstream gets incompatible with
-std=gnu++ for whatever reason.
--kcc
On Fri, Nov 14, 2014 at 11:35 AM, Andrew Pinski wrote:
> On Fri, Nov 14, 2014 at 11:29 AM, Konstantin Serebryany
>
[text-only]
On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump wrote:
> On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov wrote:
>> I can't really make my mind on this. I would mildly prefer sleep's (if
>> they work reliably!).
>
> Let me state it more forcefully.
You don't have to convince us here.
I'd love
On Mon, Jan 19, 2015 at 11:09 PM, 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
Hi,
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 -C gcc check-g{cc,++}
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp' && \
make -j 40 -C gcc check-g{cc,++}
RUNTESTFLAGS='--targ
[re-sending so that it gets to the list]
asan's design choice is to hard crash on the first error.
Doing many asan checks in the same process might become too messy too soon.
I wouldn't try to implement it myself.
Playing with longjmp in asan is not the best idea because asan
intercepts longjmp
a
Folks, please remember that the Clang flag has recently changed to
-fsanitize=address (-fsanitize=thread).
This is hopefully the last syntax change there.
--kcc
On Mon, Nov 12, 2012 at 8:45 AM, Tobias Burnus wrote:
> Jakub Jelinek:
>
>> On Mon, Nov 12, 2012 at 05:07:42PM +0100, Dodji Seketeli wr
Hi,
I don't insist that we use gtest for gcc-asan, I just say that this is
the simplest approach to get 2.5K test suite into gcc,
and the only approach my team will be able to maintain.
gtest is not as portable as the rest of gcc, but neither is asan
run-time library (which is more platform-specif
> I migrate a test in the third category. Please help to check whether
> it is ok. Then I will migrate the left. The files added are as follows
> and attached. (Please forgive I use -fasan in asan.exp because I use
> an old repository to try the migration)
>
> gcc/testsuite/lib/asan-dg.exp:
>
On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo wrote:
> On Tue, Nov 13, 2012 at 12:07 AM, David Miller wrote:
>>
>> This has broken the build on every Linux target that hasn't added
>> the necessary cpu specific code to asan_linux.cc
>
> This should be fixed by Dodji's recent patch. ASAN is not
On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek wrote:
> On Tue, Nov 13, 2012 at 03:31:21AM -0800, H.J. Lu wrote:
>> On Tue, Nov 13, 2012 at 3:20 AM, Dodji Seketeli wrote:
>> > Diego Novillo a écrit:
>> >
>> >> Patches to libsanitizer should be sent upstream. We should only
>> >> contain a copy
On Tue, Nov 13, 2012 at 1:46 PM, Andrew Pinski wrote:
> On Tue, Nov 13, 2012 at 1:40 PM, Konstantin Serebryany
> wrote:
>> On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek wrote:
>>> On Tue, Nov 13, 2012 at 03:31:21AM -0800, H.J. Lu wrote:
>>>> On Tue, Nov 13
On Tue, Nov 13, 2012 at 1:53 PM, H.J. Lu wrote:
> On Tue, Nov 13, 2012 at 1:40 PM, Konstantin Serebryany
> wrote:
>> On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek wrote:
>>> On Tue, Nov 13, 2012 at 03:31:21AM -0800, H.J. Lu wrote:
>>>> On Tue, Nov 13, 2012
On Tue, Nov 13, 2012 at 1:55 PM, Andrew Pinski wrote:
> On Tue, Nov 13, 2012 at 1:24 PM, Konstantin Serebryany
> wrote:
>>> I migrate a test in the third category. Please help to check whether
>>> it is ok. Then I will migrate the left. The files added are as follows
&
PM, Konstantin Serebryany
> wrote:
>> On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek wrote:
>>> On Tue, Nov 13, 2012 at 03:31:21AM -0800, H.J. Lu wrote:
>>>> On Tue, Nov 13, 2012 at 3:20 AM, Dodji Seketeli wrote:
>>>> > Diego Novillo a écrit:
>>>&g
On Tue, Nov 13, 2012 at 2:29 PM, Andrew Pinski wrote:
> On Tue, Nov 13, 2012 at 2:26 PM, Konstantin Serebryany
> wrote:
>> H.J.,
>> Question about this patch.
>> Will it work if we simply replace
>>#if __WORDSIZE == 64
>> with
>> #ifdef x86_64
&
On Tue, Nov 13, 2012 at 2:40 PM, H.J. Lu wrote:
> On Tue, Nov 13, 2012 at 2:39 PM, H.J. Lu wrote:
>> On Tue, Nov 13, 2012 at 2:26 PM, Konstantin Serebryany
>> wrote:
>>> H.J.,
>>> Question about this patch.
>>> Will it work if we simply replace
>>
+euge...@google.com
>>>
>>> asan run-time (and the LLVM part) works on Mac and on ARM/Linux.
>>
>> And when you say ARM / Linux, has this been tested on older versions of the
>> architecture or just v7-a ?
Evgeniy is better equipped to answer this.
At some point we've been testing asan on the ac
+dvyukov, +glider, +samsonov
Sorry I am lagging behind e-mail, but I am sure Dmitry, Alexander or
Alexey may submit the patch upstream.
Please make sure to comment the reason for using a separate typedef.
We need our custom unwinder based on frame pointers to remain the
default choice on x86[_64]
On Thu, Nov 15, 2012 at 9:25 AM, Dmitry Vyukov wrote:
> On Thu, Nov 15, 2012 at 9:19 PM, Jakub Jelinek wrote:
>> On Thu, Nov 15, 2012 at 09:05:13AM -0800, Konstantin Serebryany wrote:
>>> +dvyukov, +glider, +samsonov
>>>
>>> Sorry I am lagging behind e-mail
1 - 100 of 284 matches
Mail list logo
