This is the mail archive of the
mailing list for the GCC project.
Re: libsanitizer merge from upstream r208536
- From: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Dodji Seketeli <dseketel at redhat dot com>, Paolo Carlini <paolo dot carlini at oracle dot com>, Yury Gribov <y dot gribov at samsung dot com>, Andrew Pinski <pinskia at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Dodji Seketeli <dodji at redhat dot com>, Dmitry Vyukov <dvyukov at google dot com>, Marek Polacek <polacek at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Yuri Gribov <tetra2005 at gmail dot com>
- Date: Mon, 26 May 2014 13:19:27 +0400
- Subject: Re: libsanitizer merge from upstream r208536
- Authentication-results: sourceware.org; auth=none
- References: <20140522094737 dot GZ10386 at tucnak dot redhat dot com> <CAGQ9bdy+j4+-immgKGdUHwc6au_jRzxCnuy=ehKZozbq6Ks2Qw at mail dot gmail dot com> <20140522110348 dot GC10386 at tucnak dot redhat dot com> <20140522114335 dot GD10386 at tucnak dot redhat dot com> <CAGQ9bdza1Stavf-3iSrqDTXBTGdHPQRqLd0xVJy82YwX6Okc-w at mail dot gmail dot com> <20140522140738 dot GF10386 at tucnak dot redhat dot com> <CAGQ9bdxLE9R_X2V8z+Gu7dzzC+yrgg5pfYNUk+C2BY9JKKVu=Q at mail dot gmail dot com> <CAGQ9bdwQXfGXhr1C4U5p9_Ou5SDYM8TYfrMNHttharGuT8OOCQ at mail dot gmail dot com> <20140523164500 dot GX10386 at tucnak dot redhat dot com> <CAGQ9bdzgBL3N06H1vvVfnuL3GusFjCh+eCiBvpH13gYrsoiG4g at mail dot gmail dot com> <20140526085753 dot GC10386 at tucnak dot redhat dot com>
I was going to change instrumentation of unaligned and unusual-sized
accesses to simple callbacks.
4b1f30: 53 push %rbx
4b1f31: 48 89 fb mov %rdi,%rbx
4b1f34: be 04 00 00 00 mov $0x4,%esi
4b1f39: e8 62 9d fe ff callq 49bca0 <__asan_loadN>
4b1f3e: 8b 03 mov (%rbx),%eax
4b1f40: 5b pop %rbx
4b1f41: c3 retq
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.
clang++ -g -O2 -fsanitize=address ~/tmp/jakub-unaligned.c -mllvm
-asan-instrumentation-with-call-threshold=0 && ./a.out
==6925==ERROR: AddressSanitizer: unknown-crash on address
0x7fff9968a1af at pc 0x4b1f3e bp 0x7fff9968a160 sp 0x7fff9968a148
READ of size 4 at 0x7fff9968a1af thread T0
#0 0x4b1f3d in foo(S*) /home/kcc/tmp/jakub-unaligned.c:6
#1 0x4b205a in main /home/kcc/tmp/jakub-unaligned.c:30
#2 0x7fec5540f76c in __libc_start_main
#3 0x4b1e6c in _start (/usr/local/google/kcc/llvm_cmake/a.out+0x4b1e6c)
Address 0x7fff9968a1af is located in stack of thread T0 at offset 47 in frame
#0 0x4b1f8f in main /home/kcc/tmp/jakub-unaligned.c:23
This frame has 4 object(s):
[32, 48) 't' <== Memory access at offset 47 partially overflows
[64, 68) 'v'
[80, 88) 'p'
[112, 116) 'w'
Apparently, this "unknown-crash" needs to be fixed.
Give me some time (may not have it this week though).
On Mon, May 26, 2014 at 12:57 PM, Jakub Jelinek <email@example.com> wrote:
> 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: AddressSanitizer: stack-buffer-overflow on address
>> 0x7fffffffdf02 at pc 0x4b20db bp 0x7fffffffdd70 sp 0x7fffffffdd68
>> READ of size 4 at 0x7fffffffdf02 thread T0
>> #0 0x4b20da in foo(S*) /home/kcc/tmp/jakub-unaligned.c:6
>> #1 0x4b2744 in main /home/kcc/tmp/jakub-unaligned.c:30
>> #2 0x7ffff6bfd76c in __libc_start_main
>> #3 0x4b1e6c in _start (/usr/local/google/kcc/llvm_cmake/a.out+0x4b1e6c)
>> Address 0x7fffffffdf02 is located in stack of thread T0 at offset 66 in frame
>> #0 0x4b24ef in main /home/kcc/tmp/jakub-unaligned.c:23
> So you are passing two different base-addr values to the
> __asan_report_load_n ? If yes, that doesn't sound like a good idea to me,
> because it will almost always generate larger code, plus the diagnostic
> is incorrect, there is no 4 byte read at address 0x7fffffffdf02,
> there is a 4 byte read at address 0x7fffffffdeff, where 1 byte read at
> at 0x7fffffffdeff has been checked and found valid, and one byte read
> at 0x7fffffffdf02 has been checked and found invalid.
> So in that case IMNSHO you need to fix both asan library and llvm.