Agree.
I was going to change instrumentation of unaligned and unusual-sized
accesses to simple callbacks.
00000000004b1f30 <_Z3fooP1S>:
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
/build/buildd/eglibc-2.15/csu/libc-start.c:226
#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
this variable
[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).
--kcc
On Mon, May 26, 2014 at 12:57 PM, Jakub Jelinek <ja...@redhat.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
>> /build/buildd/eglibc-2.15/csu/libc-start.c:226
>> #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.
>
> Jakub
