[Bug sanitizer/61978] New: implement blacklist for sanitizer

[Bug sanitizer/61978] New: implement blacklist for sanitizer

[gcc at dpinol dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978

            Bug ID: 61978
           Summary: implement blacklist for sanitizer
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc at dpinol dot com
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

clang has a -fsanitize-blacklist for this

thanks

[Bug sanitizer/61978] implement blacklist for sanitizer

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is intentionally not implemented, you should mark functions you don't want
to sanitize in the source, not on the side, so just use the attribute for it.

[Bug sanitizer/61978] implement blacklist for sanitizer

[kcc at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978

--- Comment #2 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
Yea. This has been discussed a couple of times before. 
using an attribute in the source is clearly the preferable way. 
Unfortunately, it is not always technically possible, so we *have* to use the
blacklists. 
The major use cases: 
  a) third_party code that can not be easily modified 
  b) needs to blacklist an entire source directory 
  c) blacklist should be applied to a type, not a function

In Chromium we have these:
http://src.chromium.org/viewvc/chrome/trunk/src/tools/memory/tsan_v2/ignores.txt?revision=279695
http://src.chromium.org/viewvc/chrome/trunk/src/tools/msan/blacklist.txt?revision=284946
http://src.chromium.org/viewvc/chrome/trunk/src/tools/ubsan_vptr/blacklist.txt?revision=285951
http://src.chromium.org/viewvc/chrome/trunk/src/third_party/instrumented_libraries/blacklists/asan/libglib2.0-0.txt?revision=282959
http://src.chromium.org/viewvc/chrome/trunk/src/third_party/instrumented_libraries/blacklists/msan/libx11-6.txt?revision=282959

[Bug sanitizer/61978] implement blacklist for sanitizer

[gcc at dpinol dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978

--- Comment #3 from Daniel Pinol <gcc at dpinol dot com> ---
I agree with Kostya. 
I get an error within Qt, and I cannot modify its source code. Another option
would be having a flag for not aborting execution when an error is detected (as
in valgrind)

I tried adding the no_sanitize_address attribute to the method which eventually
calls the problematic function, but it did not work.

Is it possible to reopen a ticket until a solution for these kind of problems
is addressed?

thanks

#if defined(__has_feature)
#  if __has_feature(address_sanitizer)
    __attribute__((no_sanitize_address))
#  endif
#endif
    void triggerLang(ReemWindow &win, config::Language const &lang)



==15711==ERROR: AddressSanitizer: global-buffer-overflow on address 0x09de51cc
at pc 0xb7263661 bp 0xbfd89638 sp 0xbfd8961c
READ of size 21 at 0x09de51cc thread T0
    #0 0xb7263660 in __interceptor_memcmp
../../.././libsanitizer/asan/asan_interceptors.cc:325
    #1 0xb513b25b (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x1a925b)
    #2 0xb513bffa (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x1a9ffa)
    #3 0xb513cc7a in QTranslator::translate(char const*, char const*, char
const*) const (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x1aac7a)
    #4 0xb513cd13 in QTranslator::translate(char const*, char const*, char
const*, int) const (/opt/qtsdk-4.85/lib/libQtCore.so.4+0x1aad13)
    #5 0xb511bc16 in QCoreApplication::translate(char const*, char const*, char
const*, QCoreApplication::Encoding, int)
(/opt/qtsdk-4.85/lib/libQtCore.so.4+0x189c16)
    #6 0xb511c0a9 in QCoreApplication::translate(char const*, char const*, char
const*, QCoreApplication::Encoding)
(/opt/qtsdk-4.85/lib/libQtCore.so.4+0x18a0a9)
    #7 0x950803f in Ui_VideoWindow::retranslateUi(QWidget*)
/home/dani/svn/robot/gcc491-sanitizer/src/interaction/gui/touchscreen/ReemH/videoWindow/ui_VideoWindow.h:267
    #8 0x94f9cea in
pal::gui::VideoWindow::TriggerLanguageChanged(pal::config::Language const&)
/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/videoWindow/VideoWindow.cpp:146
    #9 0x982afe4 in
pal::gui::ReemWidget::triggerLanguageChanged(pal::config::Language const&)
/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemWidget.cpp:476
    #10 0x982b18a in
pal::gui::ReemWidget::triggerLanguageChanged(pal::config::Language const&)
/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemWidget.cpp:511
    #11 0x92daab5 in pal::gui::triggerLang(pal::gui::ReemWindow&,
pal::config::Language const&)
/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/ReemWindow.cpp:315

[Bug sanitizer/61978] implement blacklist for sanitizer

[kcc at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978

--- Comment #4 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
Note that the blacklist can not disable the checking inside the memcmp
interceptor. But it will disable instrumenting globals in QT, so 
if this is a global from QT (you did not post the full log) you will not see
the error.

[Bug sanitizer/61978] implement blacklist for sanitizer

[kcc at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978

--- Comment #5 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
Also check if strict_memcmp=0 helps you. 
https://code.google.com/p/address-sanitizer/wiki/Flags

[Bug sanitizer/61978] implement blacklist for sanitizer

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Daniel Pinol from comment #3)
> #if defined(__has_feature)
> #  if __has_feature(address_sanitizer)
>     __attribute__((no_sanitize_address))
> #  endif
> #endif
>     void triggerLang(ReemWindow &win, config::Language const &lang)

is not adding the attribute at all.  GCC doesn't support the clangism
__has_feature.  Just add the attribute unconditionally, uknown attributes just
cause a warning, and 4.8+ supports that attribute.

[Bug sanitizer/61978] implement blacklist for sanitizer

[gcc at dpinol dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978

--- Comment #7 from Daniel Pinol <gcc at dpinol dot com> ---
thank you everybody for your great feedback!

@kostya: I provide here the full log. Even removing the #if's, it still aborts.
strict_memcmp=0 worked like a charm. Thanks!

I guess there's no way to just report the errors but not abort execution,
right?


0x09de51cc is located 52 bytes to the left of global variable '*.LC2' from
'/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/videoWindow/VideoWindow.cpp'
(0x9de5200) of size 1
  '*.LC2' is ascii string ''
0x09de51cc is located 0 bytes to the right of global variable '*.LC1' from
'/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/videoWindow/VideoWindow.cpp'
(0x9de51c0) of size 12
  '*.LC1' is ascii string 'VideoWindow'
SUMMARY: AddressSanitizer: global-buffer-overflow
../../.././libsanitizer/asan/asan_interceptors.cc:325 __interceptor_memcmp
Shadow bytes around the buggy address:
  0x213bc9e0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x213bc9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x213bca00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x213bca10: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
  0x213bca20: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
=>0x213bca30: 00 00 00 00 00 00 00 00 00[04]f9 f9 f9 f9 f9 f9
  0x213bca40: 01 f9 f9 f9 f9 f9 f9 f9 00 00 01 f9 f9 f9 f9 f9
  0x213bca50: 00 00 01 f9 f9 f9 f9 f9 00 07 f9 f9 f9 f9 f9 f9
  0x213bca60: 00 05 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x213bca70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x213bca80: 00 01 f9 f9 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9
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
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Contiguous container OOB:fc
  ASan internal:           fe
==19590==ABORTING

[Bug sanitizer/61978] implement blacklist for sanitizer

[kcc at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978

--- Comment #8 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(In reply to Daniel Pinol from comment #7)
> thank you everybody for your great feedback!
> 
> @kostya: I provide here the full log. Even removing the #if's, it still
> aborts. strict_memcmp=0 worked like a charm. Thanks!

Good. Formally this is a bug, but in most cases not a very harmful one. 
So, just continue using strict_memcmp=0

> 
> I guess there's no way to just report the errors but not abort execution,
> right?

Right, asan exits on first error. 
(First entry in FAQ:
https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#FAQ)

> 
> 
> 0x09de51cc is located 52 bytes to the left of global variable '*.LC2' from
> '/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/
> videoWindow/VideoWindow.cpp' (0x9de5200) of size 1
>   '*.LC2' is ascii string ''
> 0x09de51cc is located 0 bytes to the right of global variable '*.LC1' from
> '/home/dani/svn/robot/sources/src/interaction/gui/touchscreen/ReemH/
> videoWindow/VideoWindow.cpp' (0x9de51c0) of size 12
>   '*.LC1' is ascii string 'VideoWindow'
> SUMMARY: AddressSanitizer: global-buffer-overflow
> ../../.././libsanitizer/asan/asan_interceptors.cc:325 __interceptor_memcmp
> Shadow bytes around the buggy address:
>   0x213bc9e0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x213bc9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x213bca00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x213bca10: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
>   0x213bca20: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
> =>0x213bca30: 00 00 00 00 00 00 00 00 00[04]f9 f9 f9 f9 f9 f9
>   0x213bca40: 01 f9 f9 f9 f9 f9 f9 f9 00 00 01 f9 f9 f9 f9 f9
>   0x213bca50: 00 00 01 f9 f9 f9 f9 f9 00 07 f9 f9 f9 f9 f9 f9
>   0x213bca60: 00 05 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x213bca70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x213bca80: 00 01 f9 f9 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9
> 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
>   Heap right redzone:      fb
>   Freed heap region:       fd
>   Stack left redzone:      f1
>   Stack mid redzone:       f2
>   Stack right redzone:     f3
>   Stack partial redzone:   f4
>   Stack after return:      f5
>   Stack use after scope:   f8
>   Global redzone:          f9
>   Global init order:       f6
>   Poisoned by user:        f7
>   Contiguous container OOB:fc
>   ASan internal:           fe
> ==19590==ABORTING

[Bug sanitizer/61978] implement blacklist for sanitizer

[manu at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6100 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Stewart Martin-Haugh from comment #9)
> Hi,
> I see this marked as WONTFIX - still, the use-cases that Kostya identifies
> are valid, I think. Would anyone be able to implement a patch, or suggest
> roughly how this might work?

Although existing GCC devs may not find this feature interesting enough to
implement it themselves, a nice, small patch properly submitted together with a
convincingly argued rationale may get accepted. It seems this feature is being
used not only by Chromium but also by LibreOffice, and many GCC users would
still like to keep using GCC for building those programs.

Many features that were initially rejected have been later accepted (e.g.,
color diagnostics). It just needs someone to get behind the idea and push for
it in the right way.
>From gcc-bugs-return-482474-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 01 09:44:39 2015
Return-Path: <gcc-bugs-return-482474-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 38388 invoked by alias); 1 Apr 2015 09:44:39 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 38056 invoked by uid 48); 1 Apr 2015 09:44:35 -0000
From: "terry.guo at arm dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65648] New: [5 Regression] Bad code due to IRA fails to recognize the clobber in parallel
Date: Wed, 01 Apr 2015 09:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: terry.guo at arm dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-65648-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg00026.txt.bz2
Content-length: 3032

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide648

            Bug ID: 65648
           Summary: [5 Regression] Bad code due to IRA fails to recognize
                    the clobber in parallel
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: terry.guo at arm dot com

Created attachment 35200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5200&actioníit
test case

When compile attached case with command:
arm-none-eabi-gcc -march=armv6-m -mthumb -Os x.c -S

The gcc generates bad code as below:
main:
        push    {r0, r1, r2, r4, r5, r6, r7, lr}
        ldr     r4, .L5
        movs    r5, #0
        ldr     r0, [r4, #8]
        add     r1, sp, #4
        rsbs    r2, r0, #0
        adcs    r2, r2, r0
        subs    r3, r2, r3  //r3 is used but not initialized

The instruction to initialize r3 is removed due to IRA failed to recognize the
clobber in reload pass. Before the reload pass, we have three instructions like
below:
(insn 12 11 14 2 (parallel [
            (set (reg:SI 128)
                (eq:SI (reg:SI 110 [ D.4914 ])
                    (const_int 0 [0])))
            (clobber (reg:SI 129))
        ]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
     (expr_list:REG_UNUSED (reg:SI 129)
        (nil)))
(insn 20 19 22 2 (set (reg:SI 135)
        (plus:SI (plus:SI (reg:SI 136)
                (reg:SI 137))
            (geu:SI (reg:SI 131 [ D.4914 ])
                (reg:SI 134 [ c ])))) x.c:23 764 {thumb1_addsi3_addgeu}
     (expr_list:REG_DEAD (reg:SI 137)
        (expr_list:REG_DEAD (reg:SI 136)
            (expr_list:REG_DEAD (reg:SI 134 [ c ])
                (expr_list:REG_DEAD (reg:SI 131 [ D.4914 ])
                    (nil))))))
(insn 22 20 23 2 (set (reg:SI 138)
        (minus:SI (reg:SI 128)
            (reg:SI 135))) x.c:23 720 {thumb1_subsi3_insn}
     (expr_list:REG_DEAD (reg:SI 135)
        (expr_list:REG_DEAD (reg:SI 128)
            (nil))))

After the reload pass, those instructions are wrongly turned into:
(insn 20 53 58 2 (set (reg:SI 3 r3 [135])
        (plus:SI (plus:SI (reg:SI 3 r3 [137])
                (reg:SI 2 r2 [136]))
            (geu:SI (reg:SI 7 r7 [orig:131 D.4914 ] [131])
                (reg:SI 6 r6 [153])))) x.c:23 764 {thumb1_addsi3_addgeu}
     (nil))
(insn 58 20 55 2 (parallel [
            (set (reg:SI 2 r2 [128])
                (eq:SI (reg:SI 0 r0 [orig:110 D.4914 ] [110])
                    (const_int 0 [0])))
            (clobber (reg:SI 3 r3 [129]))
        ]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
     (nil))
(note 55 58 22 2 NOTE_INSN_DELETED)
(insn 22 55 23 2 (set (reg:SI 3 r3 [138])
        (minus:SI (reg:SI 2 r2 [128])
            (reg:SI 3 r3 [135]))) x.c:23 720 {thumb1_subsi3_insn}
     (nil))

However the later pass can recognize the clobber in insn 58 and will remove the
insn 20 because the r3 defined in insn 20 is clobbered by insn 58.