[llvm-bugs] [Bug 33034] New: [feature request] sanitizer blacklist: specifying shared libraries

via llvm-bugs llvm-bugs at lists.llvm.org
Sun May 14 23:22:49 PDT 2017


https://bugs.llvm.org/show_bug.cgi?id=33034

            Bug ID: 33034
           Summary: [feature request] sanitizer blacklist: specifying
                    shared libraries
           Product: new-bugs
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: jhi at iki.fi
                CC: llvm-bugs at lists.llvm.org

Hi, I am trying to use the clang memory sanitizer, and that has the
understandable-but-annoying requirement that the whole executable needs to be
msan-clean.  The libc wrapper helps for 90% of the pain, but I've run into the
10% -- an external third-party library triggers the wrath of the msan.

The current blacklisting functionality
(https://clang.llvm.org/docs/SanitizerSpecialCaseList.html) allows one to
blacklist by source code path or by function name.

But in my case neither works: this external library is stripped of debug
symbols.  The only thing I know is the name of the shared object.

The good news is that by the msan error I have a pretty good on what the
external library is doing wrong, and it's open source software, so I can
actually see even better what it is likely doing wrong.

But fixing the external library is not my top priority, fixing my own software
is.  In the long run all the sanitizer errors from the whole call chain should
of course be fixed, but having to first fix all the external dependencies is
not conducive to timely fixing your own software.

Feature request: add to the sanitizer blacklist a new functionality (available
for msan, and other sanitizers), to specify the shared object/library name,
from which to ignore the sanitizer errors.  Something like this (notice the
wildcarding)

lib: /usr/lib/libfoo.so
lib: /usr/local/lib/libbar.so*

It is important to allow full control of the shared object filename since (1)
they are not *.so in every system (2) even when they are *.so, they might have
extra stuff after them like version numbers.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170515/9506a85d/attachment.html>


More information about the llvm-bugs mailing list