Hi,
On 06/16/2014 10:42 AM, Konstantin Serebryany wrote:
On Wed, Jun 11, 2014 at 2:28 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
On 05/22/2014 09:02 PM, Jakub Jelinek wrote:
In file included from
../../../../trunk/libsanitizer/asan/asan_interceptors.cc:147:0:
On Mon, Jun 23, 2014 at 07:23:09PM +0200, Paolo Carlini wrote:
/
2014-06-23 Paolo Carlini paolo.carl...@oracle.com
* sanitizer_common/sanitizer_common_interceptors.inc:
Cherry pick upstream r211008.
Sure, thanks.
Index:
On Wed, Jun 11, 2014 at 2:28 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
On 05/22/2014 09:02 PM, Jakub Jelinek wrote:
In file included from
../../../../trunk/libsanitizer/asan/asan_interceptors.cc:147:0:
Hi,
On 16/06/14 10:42, Konstantin Serebryany wrote:
I've fixed this in upstream trunk:
http://llvm.org/viewvc/llvm-project?view=revisionrevision=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
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 ja...@redhat.com writes:
[...]
Ok, tried to merge also g++.dg/asan from the same revision as you've merged
libsanitizer.
[...]
2014-05-22 Jakub Jelinek ja...@redhat.com
* g++.dg/asan/asan_test.C: Add -std=c++11 and
-DSANITIZER_USE_DEJAGNU_GTEST=1 to
Jakub Jelinek ja...@redhat.com writes:
On Thu, May 22, 2014 at 04:07:38PM +0200, Jakub Jelinek wrote:
2014-05-22 Jakub Jelinek ja...@redhat.com
* sanitizer.def (BUILT_IN_ASAN_REPORT_LOAD_N,
BUILT_IN_ASAN_REPORT_STORE_N): New.
* asan.c (struct asan_mem_ref): Change
Jakub Jelinek ja...@redhat.com writes:
[...]
Here is the GCC side of the thing,
[...]
2014-05-23 Jakub Jelinek ja...@redhat.com
* asan.c (report_error_func): Add SLOW_P argument, use
BUILT_IN_ASAN_*_N if set.
(build_check_stmt): Likewise.
(instrument_derefs):
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]$ find .
On Wed, May 28, 2014 at 8:36 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
Dmitry,
You've introduced atomic_uint64_t stats_[AllocatorStatCount]; in
http://llvm.org/viewvc/llvm-project?view=revisionrevision=173332
Do you mind to change it to atomic_uintptr_t?
There is of
On May 26, 2014, at 10:13 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com 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.
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-bit
On Tue, May 27, 2014 at 9:53 PM, Mike Stump mikest...@comcast.net wrote:
On May 26, 2014, at 10:13 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com 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
On May 27, 2014, at 11:16 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Tue, May 27, 2014 at 9:53 PM, Mike Stump mikest...@comcast.net wrote:
On May 26, 2014, at 10:13 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Mon, 2014-05-26 at 10:36
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 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_8
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 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]$ find .
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 only
On Tue, May 27, 2014 at 11:00 PM, Jakub Jelinek ja...@redhat.com 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
Dmitry,
You've introduced atomic_uint64_t stats_[AllocatorStatCount]; in
http://llvm.org/viewvc/llvm-project?view=revisionrevision=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
On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek ja...@redhat.com 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:
On Fri, May 23, 2014 at 8:45 PM, Jakub Jelinek ja...@redhat.com 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
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==ERROR:
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
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
On 23 May 2014 17:01, Evgeniy Stepanov eugeni.stepa...@gmail.com 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,
On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek ja...@redhat.com 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
On Tue, May 27, 2014 at 6:25 AM, Peter Bergner berg...@vnet.ibm.com wrote:
On Mon, May 26, 2014 at 9:57 AM, Jakub Jelinek ja...@redhat.com 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
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
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
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've seen
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
On Thu, May 22, 2014 at 7:31 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Wed, May 21, 2014 at 11:43 PM, Jakub Jelinek ja...@redhat.com 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
On Fri, May 23, 2014 at 11:20 AM, Yury Gribov y.gri...@samsung.com 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 I'm
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 usually try
On Fri, May 23, 2014 at 11:32 AM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Thu, May 22, 2014 at 7:31 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Wed, May 21, 2014 at 11:43 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, May 21, 2014 at 04:09:19PM
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. Of
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
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 noone
On Fri, May 23, 2014 at 11:56 AM, Ramana Radhakrishnan
ramana.radhakrish...@arm.com 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
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
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
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 ||
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
still should have come up on your machine in the first place.
should not have
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)
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
library which
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 when
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
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; }
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
On Fri, May 23, 2014 at 5:41 PM, Marek Polacek pola...@redhat.com 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,
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
konstantin.s.serebry...@gmail.com wrote:
On Fri, May 23, 2014 at 5:41 PM, Marek Polacek
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
On Fri, May 23, 2014 at 6:11 PM, Kugan
kugan.vivekanandara...@linaro.org 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
On Fri, May 23, 2014 at 6:12 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Fri, May 23, 2014 at 6:11 PM, Kugan
kugan.vivekanandara...@linaro.org wrote:
On 24/05/14 00:06, Christophe Lyon wrote:
Hi,
Since merge from upstream r209283 (210743 in GCC), my build fails on
On Fri, 2014-05-23 at 17:45 +0400, Konstantin Serebryany wrote:
On Fri, May 23, 2014 at 5:41 PM, Marek Polacek pola...@redhat.com 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
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
christophe.l...@linaro.org wrote:
Hi,
Since merge from upstream r209283 (210743 in GCC), my build fails on
ARM, because
On Fri, May 23, 2014 at 11:40 AM, Jakub Jelinek ja...@redhat.com 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
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
is
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
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 from
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 Wed, May 21, 2014 at 11:43 PM, Jakub Jelinek ja...@redhat.com 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
.. 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:
On Thu, May 22, 2014 at 12:54 PM, Paolo Carlini
paolo.carl...@oracle.com 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
Hi,
On 22 maggio 2014 11:05:31 CEST, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Thu, May 22, 2014 at 12:54 PM, Paolo Carlini
paolo.carl...@oracle.com wrote:
.. sorry, I didn't follow the whole thread, but today I'm seeing
loads of
failures when testing C++ on
On Thu, May 22, 2014 at 11:44:06AM +0200, Paolo Carlini wrote:
On 22 maggio 2014 11:05:31 CEST, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Thu, May 22, 2014 at 12:54 PM, Paolo Carlini
paolo.carl...@oracle.com wrote:
.. sorry, I didn't follow the whole thread, but
What is the exact command are you running?
On Thu, May 22, 2014 at 1:47 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, May 22, 2014 at 11:44:06AM +0200, Paolo Carlini wrote:
On 22 maggio 2014 11:05:31 CEST, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Thu, May 22,
Hi
On 22 maggio 2014 12:26:19 CEST, Konstantin Serebryany
konstantin.s.serebry...@gmail.com 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
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.exp is
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:
On Thu, May 22, 2014 at 3:43 PM, Jakub Jelinek ja...@redhat.com 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
On Thu, May 22, 2014 at 3:03 PM, Jakub Jelinek ja...@redhat.com 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
Oops, ignore that. Forgot -C gcc
On Thu, May 22, 2014 at 4:49 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Thu, May 22, 2014 at 3:03 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
FAIL:
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=175507view=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
On Thu, May 22, 2014 at 6:07 PM, Jakub Jelinek ja...@redhat.com 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=175507view=rev
Ah, wasn't aware of that.
Here is (so far not
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 too
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] = Ident(p)[12]
On Thu, May 22, 2014 at 04:07:38PM +0200, Jakub Jelinek wrote:
2014-05-22 Jakub Jelinek ja...@redhat.com
* 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.
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
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 r210743?
Can't
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
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, Konstantin Serebryany
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
Yuri, this comes from yours
http://llvm.org/viewvc/llvm-project?view=revisionrevision=205308
Could you please take a look?
On Thu, May 22, 2014 at 11:54 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, May 22, 2014 at 09:43:01PM +0200, Paolo Carlini wrote:
Hi,
On 05/22/2014 09:15 PM, Jakub
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
of
On Wed, May 21, 2014 at 5:09 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com 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 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 Thu, May 15, 2014 at 9:28 AM, Yury Gribov y.gri...@samsung.com 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
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 hjl.to...@gmail.com wrote:
On Tue, May 13, 2014 at 2:02 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
New patch attached.
On Thu, May 15, 2014 at 1:05 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Thu, May 15, 2014 at 9:28 AM, Yury Gribov y.gri...@samsung.com 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
On Thu, May 15, 2014 at 1:05 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com 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
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 12:07 PM, Andrew Pinski pins...@gmail.com wrote:
On Thu, May 15, 2014 at 1:05 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
H.J.,
Thanks for the patches. Please (re)send them to llvm-commits,
otherwise I can not accept them.
I think this is
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 cmake
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 filling code
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 structures. For an example on MIPS
n64: stat and stat64 are
1 - 100 of 119 matches
Mail list logo
