[llvm-bugs] [Bug 33034] New: [feature request] sanitizer blacklist: specifying shared libraries
llvm-bugs at lists.llvm.org
Sun May 14 23:22:49 PDT 2017
Bug ID: 33034
Summary: [feature request] sanitizer blacklist: specifying
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
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...
More information about the llvm-bugs