From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3394 invoked by alias); 16 Nov 2016 12:53:29 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 3372 invoked by uid 89); 16 Nov 2016 12:53:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,KAM_ASCII_DIVIDERS,SPF_PASS autolearn=no version=3.3.2 spammy=Following, buggy, legend, shadow X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Nov 2016 12:53:27 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C7EA7ABC8; Wed, 16 Nov 2016 12:53:23 +0000 (UTC) Subject: Re: [RFC][PATCH] Speed-up use-after-scope (re-writing to SSA) To: Richard Biener , Jakub Jelinek References: <20161021142617.GG7282@tucnak.redhat.com> <3a109250-0440-7438-8e1f-7e5c6d8b6580@suse.cz> <20161027172358.GN3541@tucnak.redhat.com> <606cd948-6cba-02a4-f114-35900ab53203@suse.cz> <20161101151219.GT3541@tucnak.redhat.com> <20161102095202.GL3541@tucnak.redhat.com> <20161102125609.GQ3541@tucnak.redhat.com> <20161102130612.GR3541@tucnak.redhat.com> <774a5d54-30f6-3212-ea4c-21e751356055@suse.cz> Cc: GCC Patches From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: Date: Wed, 16 Nov 2016 12:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <774a5d54-30f6-3212-ea4c-21e751356055@suse.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg01615.txt.bz2 On 11/16/2016 01:25 PM, Martin Liška wrote: > Hello > > Following patch is a candidate that re-writes VAR_DECLs that are > is_gimple_reg_type with: > my_char_25 = ASAN_POISON (); > > that is eventually transformed to: > __builtin___asan_report_use_after_scope_noabort ("my_char", 1); > > at places where my_char_25 is used. That introduces a new entry point > to ASAN runtime, reporting: > > ==18378==ERROR: AddressSanitizer: stack-use-after-scope at pc 0x0000004007b4 bp 0x000000000001 sp 0x000000400603 > ACCESS of size 1 for variable 'my_char' thread T0 > #0 0x400602 in main (/tmp/a.out+0x400602) > #1 0x7fa6e572d290 in __libc_start_main (/lib64/libc.so.6+0x20290) > #2 0x400669 in _start (/tmp/a.out+0x400669) > > SUMMARY: AddressSanitizer: stack-use-after-scope (/tmp/a.out+0x400602) in main > > I'm still not sure where exactly do the expansion of ASAN_POISON as some cleanup > after the transformation would be desired. > > Thoughts? > Thanks, > Martin > > > > There's an example: int main (void) { char *ptr; { char my_char; ptr = &my_char; } return *ptr; } $ g++ /tmp/use-after-scope-1.c -fsanitize=address -O0 && ./a.out ================================================================= ==16035==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffe76322240 at pc 0x000000400848 bp 0x7ffe76322200 sp 0x7ffe763221f8 READ of size 1 at 0x7ffe76322240 thread T0 #0 0x400847 in main (/tmp/a.out+0x400847) #1 0x7f0005739290 in __libc_start_main (/lib64/libc.so.6+0x20290) #2 0x4006b9 in _start (/tmp/a.out+0x4006b9) Address 0x7ffe76322240 is located in stack of thread T0 at offset 32 in frame #0 0x400786 in main (/tmp/a.out+0x400786) This frame has 1 object(s): [32, 33) 'my_char' <== Memory access at offset 32 is inside this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-use-after-scope (/tmp/a.out+0x400847) in main Shadow bytes around the buggy address: 0x10004ec5c3f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10004ec5c400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10004ec5c410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10004ec5c420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10004ec5c430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x10004ec5c440: 00 00 00 00 f1 f1 f1 f1[f8]f2 f2 f2 f3 f3 f3 f3 0x10004ec5c450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10004ec5c460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10004ec5c470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10004ec5c480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10004ec5c490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==16035==ABORTING $ g++ /tmp/use-after-scope-1.c -fsanitize=address -O2 && ./a.out ================================================================= ==16049==ERROR: AddressSanitizer: stack-use-after-scope at pc 0x000000400794 bp 0x000000000001 sp 0x0000004005f3 ACCESS of size 1 for variable 'my_char' thread T0 #0 0x4005f2 in main (/tmp/a.out+0x4005f2) #1 0x7f883337e290 in __libc_start_main (/lib64/libc.so.6+0x20290) #2 0x400649 in _start (/tmp/a.out+0x400649) SUMMARY: AddressSanitizer: stack-use-after-scope (/tmp/a.out+0x4005f2) in main ==16049==ABORTING Martin