On Mon, Jun 23, 2014 at 07:23:09PM +0200, Paolo Carlini wrote:
> /
> 2014-06-23 Paolo Carlini
>
> * sanitizer_common/sanitizer_common_interceptors.inc:
> Cherry pick upstream r211008.
Sure, thanks.
> Index: sanitizer_common/sanitizer_common_interceptors.inc
>
Hi,
On 06/16/2014 10:42 AM, Konstantin Serebryany wrote:
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_comm
Hi,
On 16/06/14 10:42, Konstantin Serebryany wrote:
I've "fixed" this in upstream trunk:
http://llvm.org/viewvc/llvm-project?view=revision&revision=211008 This
will get into GCC with the next merge; or feel free to cherry pick.
Excellent thanks a lot.
Meanwhile, this still smells like a bug in
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,
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 function ‘int __interceptor_accept4(int, void*, unsigned int*,
int)’:
../..
Jakub Jelinek writes:
[...]
> Here is the GCC side of the thing,
[...]
> 2014-05-23 Jakub Jelinek
>
> * asan.c (report_error_func): Add SLOW_P argument, use
> BUILT_IN_ASAN_*_N if set.
> (build_check_stmt): Likewise.
> (instrument_derefs): If T has insufficient ali
Jakub Jelinek writes:
> On Thu, May 22, 2014 at 04:07:38PM +0200, Jakub Jelinek wrote:
>> 2014-05-22 Jakub Jelinek
>>
>> * sanitizer.def (BUILT_IN_ASAN_REPORT_LOAD_N,
>> BUILT_IN_ASAN_REPORT_STORE_N): New.
>> * asan.c (struct asan_mem_ref): Change access_size type to
>> HO
Jakub Jelinek writes:
[...]
> Ok, tried to merge also g++.dg/asan from the same revision as you've merged
> libsanitizer.
[...]
>
> 2014-05-22 Jakub Jelinek
>
> * g++.dg/asan/asan_test.C: Add -std=c++11 and
> -DSANITIZER_USE_DEJAGNU_GTEST=1 to dg-options, remove
> -DASAN_U
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 05:04:52PM -0500, Peter Bergner wrote:
> On Tue, 2014-05-27 at 23:50 +0200, Jakub Jelinek wrote:
> > On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
> > > It's being called form basically two files:
> > >
> > > [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]
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 32-bit arch (the number of
mallocs in a process may easily go over 2^
On Tue, May 27, 2014 at 11:00 PM, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 11:50:33PM +0200, Jakub Jelinek wrote:
>> On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
>> > It's being called form basically two files:
>> >
>> > [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]$ fin
On Tue, 2014-05-27 at 17:04 -0500, Peter Bergner wrote:
> On Tue, 2014-05-27 at 23:50 +0200, Jakub Jelinek wrote:
> > Does ppc32 have any atomic 64-bit loads/stores (in the sense that the
> > aligned
> > 64 bits are written as one memory transaction, not each 32-bit word
> > separately)?
>
> The
On Tue, May 27, 2014 at 05:04:52PM -0500, Peter Bergner wrote:
> On Tue, 2014-05-27 at 23:50 +0200, Jakub Jelinek wrote:
> > On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
> > > It's being called form basically two files:
> > >
> > > [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]
On Tue, 2014-05-27 at 23:50 +0200, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
> > It's being called form basically two files:
> >
> > [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]$ find . -name '*.o' |
> > xargs nm -AC | grep sync_fetch_and_add_8
> >
On Tue, May 27, 2014 at 11:50:33PM +0200, Jakub Jelinek wrote:
> On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
> > It's being called form basically two files:
> >
> > [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]$ find . -name '*.o' |
> > xargs nm -AC | grep sync_fetch_and_add
On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
> It's being called form basically two files:
>
> [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]$ find . -name '*.o' | xargs
> nm -AC | grep sync_fetch_and_add_8
> ./powerpc64-linux/32/libsanitizer/sanitizer_common/.libs/sanitizer_a
On Tue, 2014-05-27 at 20:07 +0200, Jakub Jelinek wrote:
> On Mon, May 26, 2014 at 09:25:37PM -0500, Peter Bergner wrote:
> > In one of my other posts, I asked should 32-bit ports even attempt
> > to use the 2 * word_size atomics. What is the code doing such that
> > it wants to use a 2 * word_size
On May 27, 2014, at 11:16 AM, Konstantin Serebryany
wrote:
> On Tue, May 27, 2014 at 9:53 PM, Mike Stump wrote:
>>
>> On May 26, 2014, at 10:13 PM, Konstantin Serebryany
>> wrote:
On Mon, 2014-05-26 at 10:36 +0400, Konstantin Serebryany wrote:
> Because this is my default reply to an
On Tue, May 27, 2014 at 9:53 PM, Mike Stump wrote:
>
> On May 26, 2014, at 10:13 PM, Konstantin Serebryany
> wrote:
>>> On Mon, 2014-05-26 at 10:36 +0400, Konstantin Serebryany wrote:
Because this is my default reply to any such case. :)
>>>
>>> I hope that is a humorous reply and not a ser
On Mon, May 26, 2014 at 09:25:37PM -0500, Peter Bergner wrote:
> In one of my other posts, I asked should 32-bit ports even attempt
> to use the 2 * word_size atomics. What is the code doing such that
> it wants to use a 2 * word_size atomic? Is it as simple as commenting
> that code out for 32-b
On May 26, 2014, at 10:13 PM, Konstantin Serebryany
wrote:
>> On Mon, 2014-05-26 at 10:36 +0400, Konstantin Serebryany wrote:
>>> Because this is my default reply to any such case. :)
>>
>> I hope that is a humorous reply and not a serious one.
>
> Not really humorous. Our position is and alwa
On Tue, May 27, 2014 at 6:25 AM, Peter Bergner wrote:
>> On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek wrote:
>> > Doesn't look like the ppc32 port would be in any worse shape than the
>> > 64-bit
>> > one.
>> > Peter has brought a real problem, in particular the allocator now newly
>> > relyi
> On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek wrote:
> > Doesn't look like the ppc32 port would be in any worse shape than the 64-bit
> > one.
> > Peter has brought a real problem, in particular the allocator now newly
> > relying on
> > 2 x word size atomics which is definitely non-portable,
On 23 May 2014 17:01, Evgeniy Stepanov wrote:
> Hi Christophe,
>
> is there anything special about your setup? We've seen it build on
> arm/linux and arm/android correctly.
>
>
Hi,
As Kugan said, I needed to add --enable-obsolete-rpc when configuring glibc.
Thanks,
Christophe.
> On Fri, May 23
On 05/26/2014 01:19 PM, Konstantin Serebryany wrote:
This is implemented in llvm, just need a flag flip. It also needs a
performance improvement in the run-time.
This is in my TODO, just didn't have time.
FYI I have a patch that adds -asan-instrumentation-with-call-threshold
for GCC (will send
Agree.
I was going to change instrumentation of unaligned and unusual-sized
accesses to simple callbacks.
004b1f30 <_Z3fooP1S>:
4b1f30: 53 push %rbx
4b1f31: 48 89 fbmov%rdi,%rbx
4b1f34: be 04 00 00 00 mov$0x4,%e
On Mon, May 26, 2014 at 11:29:28AM +0400, Konstantin Serebryany wrote:
> > Note, I think some work is needed on the library side,
> > ERROR: AddressSanitizer: unknown-crash on address 0xffc439cf at pc
> > 0x804898e bp 0xffc438d8 sp 0xffc438cc
>
>
> With clang I get this nice report:
>
> ==20989
On Fri, May 23, 2014 at 8:45 PM, Jakub Jelinek wrote:
> On Fri, May 23, 2014 at 04:11:48PM +0400, Konstantin Serebryany wrote:
>> >> 2) it doesn't still deal with unaligned power of two accesses properly,
>> >>but neither does llvm (at least not 3.4). Am not talking about
>> >>undefined b
On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek wrote:
> On Mon, May 26, 2014 at 08:57:11AM +0400, Konstantin Serebryany wrote:
>> Last time I tried, asan did not work on ppc32 for a large number of
>> different reasons.
>
> ???
> Comparing my 4.9.0 ppc/ppc64 testresults, for 32-bit I see:
>
> FAIL
On Mon, May 26, 2014 at 08:57:11AM +0400, Konstantin Serebryany wrote:
> Last time I tried, asan did not work on ppc32 for a large number of
> different reasons.
???
Comparing my 4.9.0 ppc/ppc64 testresults, for 32-bit I see:
FAIL: c-c++-common/asan/null-deref-1.c -O0 output pattern test, is
A
Hi Peter,
Last time I tried, asan did not work on ppc32 for a large number of
different reasons.
In upstream build system ppc32 is simply disabled, so imho it should
be also disabled in the GCC build.
If there is enough interest in ppc32, please work with up on fixing
upstream and enabling the bui
On Fri, May 23, 2014 at 01:54:47PM -0500, Peter Bergner wrote:
> On Fri, 2014-05-23 at 11:47 -0500, Peter Bergner wrote:
> > The following patch gets bootstrap working again, but there seems to
> > be a large number of testsuite failures I will look into before
> > submitting the patch to the LLVM
On Fri, 2014-05-23 at 11:47 -0500, Peter Bergner wrote:
> The following patch gets bootstrap working again, but there seems to
> be a large number of testsuite failures I will look into before
> submitting the patch to the LLVM mailing list.
FYI, it looks like a huge number of the failures are fro
On Fri, 2014-05-23 at 09:25 -0500, Peter Bergner wrote:
> xagsmtp4.20140523142452.1...@vmsdvm6.vnet.ibm.com
> X-Xagent-Gateway: vmsdvm6.vnet.ibm.com (XAGSMTP4 at VMSDVM6)
>
> On Fri, 2014-05-23 at 17:45 +0400, Konstantin Serebryany wrote:
> > On Fri, May 23, 2014 at 5:41 PM, Marek Polacek wrote:
On Fri, May 23, 2014 at 04:11:48PM +0400, Konstantin Serebryany wrote:
> >> 2) it doesn't still deal with unaligned power of two accesses properly,
> >>but neither does llvm (at least not 3.4). Am not talking about
> >>undefined behavior cases where the compiler isn't told the access
> >>
On Fri, May 23, 2014 at 11:40 AM, Jakub Jelinek wrote:
> No other shared library does anything close to that, for each such library
> you can interpose any of its public symbols, either you know what you are
> doing when interposing it, or it breaks.
I think I have finally recalled why we added t
Hi Christophe,
is there anything special about your setup? We've seen it build on
arm/linux and arm/android correctly.
On Fri, May 23, 2014 at 6:06 PM, Christophe Lyon
wrote:
> Hi,
> Since merge from upstream r209283 (210743 in GCC), my build fails on
> ARM, because rpc/xdr.h is not found.
> Is
On Fri, 2014-05-23 at 17:45 +0400, Konstantin Serebryany wrote:
> On Fri, May 23, 2014 at 5:41 PM, Marek Polacek wrote:
> > On Mon, May 12, 2014 at 03:20:37PM +0400, Konstantin Serebryany wrote:
> >> 5 months' worth of changes may break any platform we are not testing
> >> ourselves
> >> (that in
On Fri, May 23, 2014 at 6:12 PM, Konstantin Serebryany
wrote:
> On Fri, May 23, 2014 at 6:11 PM, Kugan
> wrote:
>> On 24/05/14 00:06, Christophe Lyon wrote:
>>> Hi,
>>> Since merge from upstream r209283 (210743 in GCC), my build fails on
>>> ARM, because rpc/xdr.h is not found.
>>> Is this expect
On Fri, May 23, 2014 at 6:11 PM, Kugan
wrote:
> On 24/05/14 00:06, Christophe Lyon wrote:
>> Hi,
>> Since merge from upstream r209283 (210743 in GCC), my build fails on
>> ARM, because rpc/xdr.h is not found.
>> Is this expected?
> I also have the same issue. I had to build glibc with
> --enable-o
On 24/05/14 00:06, Christophe Lyon wrote:
> Hi,
> Since merge from upstream r209283 (210743 in GCC), my build fails on
> ARM, because rpc/xdr.h is not found.
> Is this expected?
I also have the same issue. I had to build glibc with
--enable-obsolete-rpc to bootstrap now.
Thanks,
Kugan
Hi,
Since merge from upstream r209283 (210743 in GCC), my build fails on
ARM, because rpc/xdr.h is not found.
Is this expected?
Thanks,
Christophe.
On 23 May 2014 15:45, Konstantin Serebryany
wrote:
> On Fri, May 23, 2014 at 5:41 PM, Marek Polacek wrote:
>> On Mon, May 12, 2014 at 03:20:37PM
On Fri, May 23, 2014 at 5:41 PM, Marek Polacek wrote:
> On Mon, May 12, 2014 at 03:20:37PM +0400, Konstantin Serebryany wrote:
>> 5 months' worth of changes may break any platform we are not testing
>> ourselves
>> (that includes Ubuntu 12.04, 13.10, 14.04, Mac 10.9, Windows 7, Android ARM),
>> p
On Mon, May 12, 2014 at 03:20:37PM +0400, Konstantin Serebryany wrote:
> 5 months' worth of changes may break any platform we are not testing ourselves
> (that includes Ubuntu 12.04, 13.10, 14.04, Mac 10.9, Windows 7, Android ARM),
> please help us test this patch on your favorite platform.
On pow
>> 2) it doesn't still deal with unaligned power of two accesses properly,
>>but neither does llvm (at least not 3.4). Am not talking about
>>undefined behavior cases where the compiler isn't told the access
>>is misaligned, but e.g. when accessing struct S { int x; }
>>__attribute
Hi,
On 05/23/2014 12:26 PM, Yury Gribov wrote:
>> Could you add something like
>
> It's always linux-vdso.so.1, but wasn't that already known, given the
> ldd requested by Jakub?!?
Well, for me dlpi_name for vdso was empty string hence I kept asking.
I also thought that ldd and dl_iterate_phdr
>> Could you add something like
>
> It's always linux-vdso.so.1, but wasn't that already known, given the
> ldd requested by Jakub?!?
Well, for me dlpi_name for vdso was empty string hence I kept asking. I
also thought that ldd and dl_iterate_phdr might have used slightly
different code paths w
On Fri, May 23, 2014 at 11:25:02AM +0200, Paolo Carlini wrote:
> >>How do I print dlpi_name?
> >
> >Could you add something like
> > Report("'%s'\n", info->dlpi_name);
> >after
> > if (!info->dlpi_name || info->dlpi_name[0] == 0)
> >check in FindFirstDSOCallback? This should give us the name of
>
Hi,
On 05/23/2014 11:21 AM, Yury Gribov wrote:
I've checked all available systems and wasn't able to repro this.
Given your exchanges with Jakub I thought that at this point it was
clear that the issue is real.
There are three issues here:
1) whether warning should cause termination
2) wheth
> still should have come up on your machine in the first place.
should not have
I've checked all available systems and wasn't able to repro this.
Given your exchanges with Jakub I thought that at this point it was
clear that the issue is real.
There are three issues here:
1) whether warning should cause termination
2) whether warning should be displayed by default
3) why
Hi,
On 05/23/2014 10:50 AM, Yury Gribov wrote:
Paolo,
I've checked all available systems and wasn't able to repro this.
Given your exchanges with Jakub I thought that at this point it was
clear that the issue is real.
Every time vDSO was already filtered with
if (!info->dlpi_name || info->
Paolo,
I've checked all available systems and wasn't able to repro this.
Every time vDSO was already filtered with
if (!info->dlpi_name || info->dlpi_name[0] == 0)
return 0;
in FindFirstDSOCallback.
Could you provide additional details of your setup? Or perhaps print
dlpi_name of offend
Hi,
On 05/23/2014 09:47 AM, Jakub Jelinek wrote:
On Fri, May 23, 2014 at 11:34:38AM +0400, Konstantin Serebryany wrote:
Failing to intercept something may cause not just false negatives, but
also false positives.
These cases are often exceptionally hard to debug, so any checking that
the interc
On Fri, May 23, 2014 at 11:56 AM, Ramana Radhakrishnan
wrote:
> On 05/23/14 08:50, Yury Gribov wrote:
>>
>> > On ARM the asan tests have always been a random generator of PASS /
>> > FAIL on qemu despite efforts to "nobble" qemu for /proc/self/maps
>> > outputs.
>>
>> This should improve onc
On 05/23/14 08:50, Yury Gribov wrote:
> On ARM the asan tests have always been a random generator of PASS /
> FAIL on qemu despite efforts to "nobble" qemu for /proc/self/maps
> outputs.
This should improve once upstream Asan sets up an ARM build bot. This
has been discussed recently but n
> On ARM the asan tests have always been a random generator of PASS /
> FAIL on qemu despite efforts to "nobble" qemu for /proc/self/maps
> outputs.
This should improve once upstream Asan sets up an ARM build bot. This
has been discussed recently but noone has yet volunteered to do the
server i
On Fri, May 23, 2014 at 11:34:38AM +0400, Konstantin Serebryany wrote:
> Failing to intercept something may cause not just false negatives, but
> also false positives.
> These cases are often exceptionally hard to debug, so any checking that
> the interception machinery works as intended is good. O
On Fri, May 23, 2014 at 11:32 AM, Ramana Radhakrishnan
wrote:
> On Thu, May 22, 2014 at 7:31 AM, Konstantin Serebryany
> wrote:
>> On Wed, May 21, 2014 at 11:43 PM, Jakub Jelinek wrote:
>>> On Wed, May 21, 2014 at 04:09:19PM +0400, Konstantin Serebryany wrote:
A new patch based on r209283.
On Fri, May 23, 2014 at 11:20:01AM +0400, Yury Gribov wrote:
> >Even before this exaggerated check asan imposes far more restrictions than
> >good, and this just makes asan less usable just for fear that it wouldn't
> >work right.
>
> Ok, we seem to approach this from two different angles.
> I usu
On Fri, May 23, 2014 at 11:20 AM, Yury Gribov wrote:
> On 05/23/2014 10:34 AM, Jakub Jelinek wrote:
Otherwise libasan apps will simply stop
working altogether if LD_PRELOAD is set, to whatever library,
even if it doesn't define any symbols you care about.
>>>
>>>
>>> Right but
On Thu, May 22, 2014 at 7:31 AM, Konstantin Serebryany
wrote:
> On Wed, May 21, 2014 at 11:43 PM, Jakub Jelinek wrote:
>> On Wed, May 21, 2014 at 04:09:19PM +0400, Konstantin Serebryany wrote:
>>> A new patch based on r209283.
>>> This one has the H.J.'s patches for x32.
>>
>> Ok for trunk then.
On 05/23/2014 10:34 AM, Jakub Jelinek wrote:
Otherwise libasan apps will simply stop
working altogether if LD_PRELOAD is set, to whatever library,
even if it doesn't define any symbols you care about.
Right but I'm not sure whether failing fast here is necessarily bad.
I think it is very bad.
On Fri, May 23, 2014 at 09:30:12AM +0400, Yury Gribov wrote:
> > much better would be just dlsym a couple of
> > interesting symbols to verify that libasan.so.1 is ahead
> > of libc.so.6, libstdc++.so.6, libpthread.so.0 (whatever else
> > you want to override).
>
> One problem with dlsym() that I'
On 05/22/2014 11:54 PM, Jakub Jelinek wrote:
> Kostya, guess you should ignore the vDSO.
Right, we didn't encounter this problem when testing on our kernels.
I'll cook a patch for this.
> much better would be just dlsym a couple of
> interesting symbols to verify that libasan.so.1 is ahead
> o
Yuri, this comes from yours
http://llvm.org/viewvc/llvm-project?view=revision&revision=205308
Could you please take a look?
On Thu, May 22, 2014 at 11:54 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 09:43:01PM +0200, Paolo Carlini wrote:
>> Hi,
>>
>> On 05/22/2014 09:15 PM, Jakub Jelinek wr
On Thu, May 22, 2014 at 09:43:01PM +0200, Paolo Carlini wrote:
> Hi,
>
> On 05/22/2014 09:15 PM, Jakub Jelinek wrote:
> >Do you have LD_PRELOAD set in the environment?
> I don't.
> >If not, can you cut'n'paste the large-func-test-1.exe command line
> >and run it with the given LD_LIBRARY_PATH unde
Hi,
On 05/22/2014 09:15 PM, Jakub Jelinek wrote:
Do you have LD_PRELOAD set in the environment?
I don't.
If not, can you cut'n'paste the large-func-test-1.exe command line and
run it with the given LD_LIBRARY_PATH under ldd? Jakub
Sure. This is what I get:
linux-vdso.so.1 (0x7ff
On Thu, May 22, 2014 at 09:03:44PM +0200, Paolo Carlini wrote:
> Hi,
>
> On 05/22/2014 09:02 PM, Jakub Jelinek wrote:
> >On Thu, May 22, 2014 at 08:38:31PM +0200, Paolo Carlini wrote:
> >>Hi,
> >>
> >>On 05/22/2014 01:03 PM, Jakub Jelinek wrote:
> >>>On Thu, May 22, 2014 at 02:26:19PM +0400, Konst
Hi,
On 05/22/2014 09:02 PM, Jakub Jelinek wrote:
On Thu, May 22, 2014 at 08:38:31PM +0200, Paolo Carlini wrote:
Hi,
On 05/22/2014 01:03 PM, Jakub Jelinek wrote:
On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution t
On Thu, May 22, 2014 at 08:38:31PM +0200, Paolo Carlini wrote:
> Hi,
>
> On 05/22/2014 01:03 PM, Jakub Jelinek wrote:
> >On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
> >>FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
> >Is that before or after r21
Hi,
On 05/22/2014 01:03 PM, Jakub Jelinek wrote:
On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
Is that before or after r210743?
Can't reproduce the above (note, not bootstrapped compiler, just
--disable-b
On Thu, May 22, 2014 at 04:07:38PM +0200, Jakub Jelinek wrote:
> 2014-05-22 Jakub Jelinek
>
> * sanitizer.def (BUILT_IN_ASAN_REPORT_LOAD_N,
> BUILT_IN_ASAN_REPORT_STORE_N): New.
> * asan.c (struct asan_mem_ref): Change access_size type to
> HOST_WIDE_INT.
> (asan_m
>
>> > 3) there is still a failure for -m32:
>> > FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_UAF_long_double
>> > Ident(p)[12] = 0 output pattern test
>> > Output should match: WRITE of size 1[06]
>> > FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_UAF_long_double
>> > Ident(p)[0]
On Thu, May 22, 2014 at 06:34:22PM +0400, Konstantin Serebryany wrote:
> > Notes:
> > 1) the cases where we e.g. for various stringops perform first and
> >last address check and use separate __asan_report_*1 for reporting
> >that should probably be converted to use this __asan_report_*_n t
On Thu, May 22, 2014 at 6:07 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 04:06:21PM +0400, Konstantin Serebryany wrote:
>> Not really recently... (Feb 2013)
>> http://llvm.org/viewvc/llvm-project?rev=175507&view=rev
>
> Ah, wasn't aware of that.
>
> Here is (so far not bootstrapped/regteste
On Thu, May 22, 2014 at 04:06:21PM +0400, Konstantin Serebryany wrote:
> Not really recently... (Feb 2013)
> http://llvm.org/viewvc/llvm-project?rev=175507&view=rev
Ah, wasn't aware of that.
Here is (so far not bootstrapped/regtested) patch for the GCC side.
Notes:
1) the cases where we e.g. for
Oops, ignore that. Forgot -C gcc
On Thu, May 22, 2014 at 4:49 PM, Konstantin Serebryany
wrote:
> On Thu, May 22, 2014 at 3:03 PM, Jakub Jelinek wrote:
>> On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
>>> >> >> FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution te
On Thu, May 22, 2014 at 3:03 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
>> >> >> FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
>> >> >Is that before or after r210743?
>
> Can't reproduce the above (note, not bootstrapped comp
On Thu, May 22, 2014 at 3:43 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 01:03:48PM +0200, Jakub Jelinek wrote:
>> There are various other changes to asan_test.cc, so guess some work is
>> needed on that.
>
> Ok, tried to merge also g++.dg/asan from the same revision as you've merged
> lib
On Thu, May 22, 2014 at 01:03:48PM +0200, Jakub Jelinek wrote:
> There are various other changes to asan_test.cc, so guess some work is needed
> on that.
Ok, tried to merge also g++.dg/asan from the same revision as you've merged
libsanitizer.
On x86_64-linux, both -m32 and -m64 I see
FAIL: g++
On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
> >> >> FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
> >> >Is that before or after r210743?
Can't reproduce the above (note, not bootstrapped compiler, just
--disable-bootstrap), check-gcc RUNTESTFLAGS=asan.e
Hi
On 22 maggio 2014 12:26:19 CEST, Konstantin Serebryany
wrote:
>What is the exact command are you running?
Sorry, now I'm traveling. But nothing special, a very simple c and c++ build on
x86_64-linux. No special flags, all defaults. If nobody can reproduce I'll try
to fetch again the tree
What is the exact command are you running?
On Thu, May 22, 2014 at 1:47 PM, Jakub Jelinek wrote:
> On Thu, May 22, 2014 at 11:44:06AM +0200, Paolo Carlini wrote:
>> On 22 maggio 2014 11:05:31 CEST, Konstantin Serebryany
>> wrote:
>> >On Thu, May 22, 2014 at 12:54 PM, Paolo Carlini
>> > wrote:
>
On Thu, May 22, 2014 at 11:44:06AM +0200, Paolo Carlini wrote:
> On 22 maggio 2014 11:05:31 CEST, Konstantin Serebryany
> wrote:
> >On Thu, May 22, 2014 at 12:54 PM, Paolo Carlini
> > wrote:
> >> .. sorry, I didn't follow the whole thread, but today I'm seeing
> >loads of
> >> failures when testi
Hi,
On 22 maggio 2014 11:05:31 CEST, Konstantin Serebryany
wrote:
>On Thu, May 22, 2014 at 12:54 PM, Paolo Carlini
> wrote:
>> .. sorry, I didn't follow the whole thread, but today I'm seeing
>loads of
>> failures when testing C++ on x86_64-linux, beginning with:
>>
>> FAIL: c-c++-common/asan/
On Thu, May 22, 2014 at 12:54 PM, Paolo Carlini
wrote:
> .. sorry, I didn't follow the whole thread, but today I'm seeing loads of
> failures when testing C++ on x86_64-linux, beginning with:
>
> FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
Is that before or after r210743?
> FAI
.. sorry, I didn't follow the whole thread, but today I'm seeing loads
of failures when testing C++ on x86_64-linux, beginning with:
FAIL: c-c++-common/asan/asan-interface-1.c -O0 execution test
FAIL: c-c++-common/asan/asan-interface-1.c -O1 execution test
FAIL: c-c++-common/asan/asan-interf
On Wed, May 21, 2014 at 11:43 PM, Jakub Jelinek wrote:
> On Wed, May 21, 2014 at 04:09:19PM +0400, Konstantin Serebryany wrote:
>> A new patch based on r209283.
>> This one has the H.J.'s patches for x32.
>
> Ok for trunk then. But please help the ppc*/arm*/sparc* maintainers if
> issues on
> th
On Wed, May 21, 2014 at 04:09:19PM +0400, Konstantin Serebryany wrote:
> A new patch based on r209283.
> This one has the H.J.'s patches for x32.
Ok for trunk then. But please help the ppc*/arm*/sparc* maintainers if issues
on
those targets are reported.
Thanks.
Jakub
On Wed, May 21, 2014 at 5:09 AM, Konstantin Serebryany
wrote:
> A new patch based on r209283.
> This one has the H.J.'s patches for x32.
>
This one is good on x32.
Thanks.
--
H.J.
On Thu, May 15, 2014 at 12:20:06PM +0400, Yury Gribov wrote:
> On 05/15/2014 12:05 PM, Konstantin Serebryany wrote:
> >No. We have to support too many build systems and hence do not want
> >any configure step.
> >All configuration has to be done in the sources.
>
> Yeah, I see your point. But fill
On Thu, May 15, 2014 at 12:07 PM, Andrew Pinski wrote:
> On Thu, May 15, 2014 at 1:05 AM, Konstantin Serebryany
> wrote:
>> H.J.,
>> Thanks for the patches. Please (re)send them to llvm-commits,
>> otherwise I can not accept them.
>
>
> I think this is bogus reasoning. You should be able to take
>
> I think this argument is bogus. Please do one build system and
> support it. Simple makefile and some scripts seems simple to support
> so you don't need anything extra.
Would be glad to. One (but not the only) prerequisite for that GCC
exports libsanitizer
as "svn external" and uses our cm
On 05/15/2014 12:05 PM, Konstantin Serebryany wrote:
No. We have to support too many build systems and hence do not want
any configure step.
All configuration has to be done in the sources.
Yeah, I see your point. But filling code with magic constants isn't very
nice either.
We could make a
On Thu, May 15, 2014 at 1:05 AM, Konstantin Serebryany
wrote:
> H.J.,
> Thanks for the patches. Please (re)send them to llvm-commits,
> otherwise I can not accept them.
I think this is bogus reasoning. You should be able to take and post
them yourself. Those patches.
Thanks,
Andrew Pinski
>
H.J.,
Thanks for the patches. Please (re)send them to llvm-commits,
otherwise I can not accept them.
--kcc
On Wed, May 14, 2014 at 2:31 AM, H.J. Lu wrote:
> On Tue, May 13, 2014 at 2:02 AM, Konstantin Serebryany
> wrote:
>> New patch attached.
>> It is based on r208674 which enables LeakSanitiz
On Thu, May 15, 2014 at 1:05 AM, Konstantin Serebryany
wrote:
> On Thu, May 15, 2014 at 9:28 AM, Yury Gribov wrote:
>> On 05/14/2014 08:51 AM, Konstantin Serebryany wrote:
One theme I have been noticing in the libsanitizer code is that it has
all of the knowledge of glibc when it c
On Thu, May 15, 2014 at 9:28 AM, Yury Gribov wrote:
> On 05/14/2014 08:51 AM, Konstantin Serebryany wrote:
>>>
>>> One theme I have been noticing in the libsanitizer code is that it has
>>> all of the knowledge of glibc when it comes to syscalls but makes some
>>> bad assumptions dealing with some
1 - 100 of 121 matches
Mail list logo
