On Fri, Nov 15, 2013 at 11:10:18AM +0100, Jakub Jelinek wrote:
> 2013-11-15 Jakub Jelinek
>
> * cfgexpand.c (struct stack_vars_data): Add asan_base and asan_alignb
> fields.
> (expand_stack_vars): For -fsanitize=address, use (and set initially)
> data->asan_base as base
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 byte aligned variable,
>> Do these happen?
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 le
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:
>> >> I afraid it actually wants the
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:
> >> I afraid it actually wants the header (magic, descr, pc) to be in the
> >> first 3 words in
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_malloc_*
>> FakeStack::AddrIsInFakeStac
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
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 Thu, Nov 14, 2013 at 09:56:36PM +04
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 Thu, Nov 14, 2013 at 09:56:36PM +0400, Konstantin Serebryany wrote:
> >> > I thought about alig
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
>> > interface/comments.
>> > The
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 pur
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 << (c
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_return.
>> So, to use the st
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 Wed, Nov 6, 2013 at 3:53 AM, Jakub Jelinek 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
> aio whe
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
st
On Tue, Nov 5, 2013 at 10:45 AM, Jakub Jelinek 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 wrote:
>> > On Tue, 2013-11-05 at 09:57 -0600, Peter Bergner wrote:
>> >> On Tue, 2013-11-05 at 08:19 +0100, Jakub Jelinek wr
On Tue, Nov 05, 2013 at 10:17:09AM -0800, Evgeniy Stepanov wrote:
> On Tue, Nov 5, 2013 at 10:07 AM, Peter Bergner 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 , so the ch
On Tue, Nov 5, 2013 at 10:07 AM, Peter Bergner 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 , so the chances of that
>> > header actually working for you are low. glibc instead
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 , so the chances of that
> > header actually working for you are low. glibc instead just defines the
> > structures itself for each of the arch
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
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 s
On Tue, Nov 5, 2013 at 2:24 PM, H.J. Lu 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 kernel headers
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 wrote:
> It is a different failure. There are 3 problems:
>
> 1. Hard cod
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 Sere
Hello!
2013-11-04 Kostya Serebryany
* 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 (sanitizer_common_files): Added
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 v
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
wrote:
> Hi Peter,
>
> The buildbot shows the latest LLVM ppc64 build is working ok:
>
> http://lab.llvm.org:8011/builders/llvm-ppc64-linux2/builds/8086
>
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?
>> We'll need to fix it there to
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?
> 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 M
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, K
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 th
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 tested on Mac an
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
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 is supported on Mac.
>> clang-asan *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
+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 diff
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.ex
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
* g++.dg/asan/asan_test.cc: Update the test
to match the fresh asan run-time.
* c-c++-common/
On Fri, Nov 01, 2013 at 04:13:05PM -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): New function.
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
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
2>&1
/tmp/ccgSw6NI.lto.o: In function `main':
../gcc/gcc/testsuite/c-c++-common/asan
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
../gcc/gc
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 the use
> after return, do y
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 v
> On Wed, Oct 2, 2013 at 12:51 PM, Konstantin Serebryany
> > 2013-10-XX Kostya Serebryany
> >
> > * 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
> >
> >
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
> >> 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
+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.
>> This is the first full merge since 2013-02
49 matches
Mail list logo
