This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libsanitizer merge from upstream r208536


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 <jakub@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]