On Fri, Nov 15, 2013 at 11:10:18AM +0100, Jakub Jelinek wrote:
2013-11-15 Jakub Jelinek ja...@redhat.com
* cfgexpand.c (struct stack_vars_data): Add asan_base and asan_alignb
fields.
(expand_stack_vars): For -fsanitize=address, use (and set initially)
On Thu, Nov 14, 2013 at 10:09 PM, Jakub Jelinek ja...@redhat.com 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
interface/comments.
On Fri, Nov 15, 2013 at 12:06:25PM +0400, Konstantin Serebryany wrote:
On Thu, Nov 14, 2013 at 10:09 PM, Jakub Jelinek ja...@redhat.com 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
On Fri, Nov 15, 2013 at 2:10 PM, Jakub Jelinek ja...@redhat.com 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 ja...@redhat.com wrote:
On Thu, Nov 14, 2013 at 07:08:17PM +0100, Jakub Jelinek wrote:
On Thu, Nov 14,
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_malloc_*
FakeStack::AddrIsInFakeStack(addr) returns the beginning of the allocated
chunk
and then
On Fri, Nov 15, 2013 at 6:33 PM, Jakub Jelinek ja...@redhat.com 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_malloc_*
On Fri, Nov 15, 2013 at 06:46:25PM +0400, Konstantin Serebryany wrote:
On Fri, Nov 15, 2013 at 6:33 PM, Jakub Jelinek ja...@redhat.com 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
On Fri, Nov 15, 2013 at 7:18 PM, Jakub Jelinek ja...@redhat.com 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 ja...@redhat.com wrote:
On Fri, Nov 15, 2013 at 06:12:07PM +0400, Konstantin Serebryany wrote:
I afraid
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 byte aligned variable,
Do these happen?
They are supported and some programs do use them, perhaps less
On Fri, Nov 15, 2013 at 10:36 PM, Jakub Jelinek ja...@redhat.com 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 byte aligned variable,
Do these
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_return.
So, to use the stack-use-after-return feature you should simply
compile with
On Thu, Nov 14, 2013 at 7:33 PM, Jakub Jelinek ja...@redhat.com 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_return.
So, to
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
interface/comments.
The alignment should be min(4096, N), which is enough for most purposes.
You mean max(4096, N), right? And, what exactly is N? 1
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
interface/comments.
The alignment should be min(4096, N), which is enough for most purposes.
On Tue, Nov 05, 2013 at 01:49:43PM -0800, Evgeniy Stepanov wrote:
This way we can't test kernel interfaces that are not used in glibc,
like linux aio.
So you just test what you can test. Why do you need to intercept kernel
aio when hardly anything uses it? Also, what is the reason why say
On Wed, Nov 6, 2013 at 3:53 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 05, 2013 at 01:49:43PM -0800, Evgeniy Stepanov wrote:
This way we can't test kernel interfaces that are not used in glibc,
like linux aio.
So you just test what you can test. Why do you need to intercept kernel
Hello!
2013-11-04 Kostya Serebryany k...@google.com
* All source files: Merge from upstream r191666.
* merge.sh: Added lsan.
* configure.ac (AC_CONFIG_FILES): Added lsan.
* Makefile.am (SUBDIRS): Added lsan.
* sanitizer_common/Makefile.am
It is a different failure. There are 3 problems:
1. Hard coded 64-bit registers for pointers in x86-64 asm statements.
2. Treat WORD_SIZE == 32 as ia32 for machine state on x86-64.
3. On x86-64, assume ia32 FS system calls when LP64 is false.
H.J.
On Mon, Nov 4, 2013 at 10:35 PM, Konstantin
Another problem is internal_syscall casts pointers to
uint64. It doesn't work for x32 since 32-bit pointers are
signed extended to int64. We can need to cast pointer
to uptr first.
On Tue, Nov 5, 2013 at 3:23 AM, H.J. Lu hjl.to...@gmail.com wrote:
It is a different failure. There are 3
On Tue, Nov 5, 2013 at 2:24 PM, H.J. Lu hjl.to...@gmail.com wrote:
Another problem is internal_syscall casts pointers to
uint64. It doesn't work for x32 since 32-bit pointers are
signed extended to int64. We can need to cast pointer
to uptr first.
Another issue is that it breaks with 2.6.32
Hi Kostya,
As an aside, all of these asan tests have failed on
powerpc64le-unknown-linux-gnu since we began testing that target. I
have not yet had time to investigate why. Do you think there may be an
implicit or explicit assumption anywhere that PowerPC64 is big endian?
This is generally not
On Tue, 2013-11-05 at 08:19 +0100, Jakub Jelinek wrote:
On Mon, Nov 04, 2013 at 05:48:31PM -0800, Konstantin Serebryany wrote:
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).
I bet on all targets, not just
On Tue, Nov 5, 2013 at 10:07 AM, Peter Bergner berg...@vnet.ibm.com wrote:
On Tue, 2013-11-05 at 09:57 -0600, Peter Bergner wrote:
On Tue, 2013-11-05 at 08:19 +0100, Jakub Jelinek wrote:
Note, not even glibc itself includes asm/stat.h, so the chances of that
header actually working for you
On Tue, Nov 05, 2013 at 10:17:09AM -0800, Evgeniy Stepanov wrote:
On Tue, Nov 5, 2013 at 10:07 AM, Peter Bergner berg...@vnet.ibm.com wrote:
On Tue, 2013-11-05 at 09:57 -0600, Peter Bergner wrote:
On Tue, 2013-11-05 at 08:19 +0100, Jakub Jelinek wrote:
Note, not even glibc itself includes
On Tue, Nov 5, 2013 at 10:45 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 05, 2013 at 10:17:09AM -0800, Evgeniy Stepanov wrote:
On Tue, Nov 5, 2013 at 10:07 AM, Peter Bergner berg...@vnet.ibm.com wrote:
On Tue, 2013-11-05 at 09:57 -0600, Peter Bergner wrote:
On Tue, 2013-11-05 at
+glider, our Mac expert.
Hi Jack,
This patch has not been tested on Mac and we generally do not claim
that gcc-asan is supported on Mac.
clang-asan *is* supported on Mac and our bots are green (this patch is
a merge of the sources which are regularly tested on Mac,
but the build procedure is
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 is supported on Mac.
clang-asan *is* supported on Mac and our bots are green (this patch is
a merge
On Mon, Nov 4, 2013 at 8:46 AM, Jack Howarth howa...@bromo.med.uc.edu 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 is supported on Mac.
On Mon, 2013-11-04 at 06:47 -0800, Konstantin Serebryany wrote:
This patch has not been tested on Mac and we generally do not claim
that gcc-asan is supported on Mac.
clang-asan *is* supported on Mac and our bots are green (this patch is
a merge of the sources which are regularly tested on
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 berg...@vnet.ibm.com wrote:
On Mon, 2013-11-04 at 06:47 -0800, Konstantin Serebryany wrote:
This patch has not
On Mon, 2013-11-04 at 17:48 -0800, Konstantin Serebryany wrote:
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).
I'm not sure. Bill, can you fire off a quick LLVM trunk build on
powerpc64-linux and see you see the
Hi Peter,
The buildbot shows the latest LLVM ppc64 build is working ok:
http://lab.llvm.org:8011/builders/llvm-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,
It also breaks x32 build.
On Mon, Nov 4, 2013 at 5:48 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
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,
Is this the same failure or different?
On Mon, Nov 4, 2013 at 9:49 PM, H.J. Lu hjl.to...@gmail.com wrote:
It also breaks x32 build.
On Mon, Nov 4, 2013 at 5:48 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
Hi Peter.
Does this also mean that asan in llvm trunk is broken
Bill,
This build does not seem to be testing any of the asan code: you need
check-asan
--kcc
On Mon, Nov 4, 2013 at 7:30 PM, Bill Schmidt
wschm...@linux.vnet.ibm.com wrote:
Hi Peter,
The buildbot shows the latest LLVM ppc64 build is working ok:
On Mon, Nov 04, 2013 at 05:48:31PM -0800, Konstantin Serebryany wrote:
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).
I bet on all targets, not just PPC. By including kernel headers directly,
you are entering
On Fri, Nov 01, 2013 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 with...
make -k check RUNTESTFLAGS=asan.exp
On Fri, Nov 01, 2013 at 04:13:05PM -0700, Konstantin Serebryany wrote:
2013-10-XX Kostya Serebryany k...@google.com
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): New
Fixed all.
I'll commit on Monday so that I can respond to any failures if they
appear quickly.
Thanks!
--kcc
=== gcc/testsuite/ChangeLog
2013-11-04 Kostya Serebryany k...@google.com
* g++.dg/asan/asan_test.cc: Update the test
to match the fresh asan run-time.
On Tue, Oct 29, 2013 at 05:15:24PM -0700, Konstantin Serebryany wrote:
Actually, I guessed the flags:
You don't have to guess them, if you look into
testsuite/g++/g++.log (or testsuite/gcc/gcc.log etc.), you can find them
there.
% ../gcc-inst/bin/g++ -g -fsanitize=address -static-libasan -O2
On Wed, Oct 2, 2013 at 12:51 PM, Konstantin Serebryany
2013-10-XX Kostya Serebryany k...@google.com
* g++.dg/asan/asan_test.cc: Update the test
to match the fresh asan run-time.
* c-c++-common/asan/stack-overflow-1.c: Ditto.
=== gcc/ChangeLog
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 the use
after return, do you emit always the the __asan_*malloc/free calls for the
stack
On Tue, Oct 29, 2013 at 6:52 AM, Jakub Jelinek ja...@redhat.com 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 the use
after
Jakub,
Your patch seems to do what it should:
% ../gcc-inst/bin/g++ -gdwarf-2 -fsanitize=address -static-libasan
../gcc/gcc/testsuite/c-c++-common/asan/stack-overflow-1.c ./a.out
...
Address 0x7fffb8ec95ca is located in stack of thread T0 at offset 42 in frame
#0 0x44bd73 in main
Actually, I guessed the flags:
% ../gcc-inst/bin/g++ -g -fsanitize=address -static-libasan -O2 -flto
-fno-use-linker-plugin -flto-partition=none
../gcc/gcc/testsuite/c-c++-common/asan/stack-overflow-1.c; ./a.out
21
/tmp/ccgSw6NI.lto.o: In function `main':
+dnovillo, davidxl
Any suggestions?
On Wed, Oct 2, 2013 at 12:54 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
re-sending with compressed patch attached
On Wed, Oct 2, 2013 at 12:51 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
Hi,
I'd like to
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,-m64\}
asan.exp'
Since the change also pulls minor changes in ubsan, please suggest me
how to test that too.
We
Thanks!
(I still need more suggestions/review :)
On Mon, Oct 14, 2013 at 3:48 PM, Marek Polacek pola...@redhat.com 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,++}
48 matches
Mail list logo
