RFC: Sanitizer: Make SuppressionContext tool-specific

Alexey Samsonov vonosmas at gmail.com
Thu Feb 19 14:11:13 PST 2015


On Thu, Feb 19, 2015 at 12:26 AM, Alexander Potapenko <glider at google.com>
wrote:

> Will it be possible to combine LSan and ASan suppressions in a single file?
> (I'm not quite sure we want this, though)
>

We might add this functionality as needed (allow suppressions file for
"parent tool" (ASan) contain entries for plugin tools (LSan, UBSan).


> The idea sounds good to me in general.
>

OK, thanks.


>
> On Thu, Feb 19, 2015 at 7:46 AM, Dmitry Vyukov <dvyukov at google.com> wrote:
> > +glider
> > sounds good to me
> > but probably not super top priority
> >
> >
> > On Thu, Feb 19, 2015 at 3:02 AM, Alexey Samsonov <vonosmas at gmail.com>
> wrote:
> >> Hi,
> >>
> >> TL;DR Let's make each sanitizer has its own suppression context.
> >>
> >> So now there are four  sanitizers that support suppressions: TSan, LSan,
> >> UBSan, ASan; and 12 types of suppressions (TSan has 7, LSan and UBSan
> has 1,
> >> ASan has 3, none are shared).
> >>
> >> The only way to use suppressions is via SuppressionContext singleton
> from
> >> sanitizer_common library. I propose to make SuppressionContext a regular
> >> class and let each sanitizer use its own, specialized version of it.
> >> "suppressions" runtime flag will be removed from CommonFlags, and
> instead
> >> added to each of: TsanFlags, UbsanFlags, AsanFlags, LsanFlags.
> >>
> >> This will allow us to:
> >> 1) specify different suppression files for each sanitizer, which is
> useful
> >> if they are combined
> >> $ ASAN_OPTIONS=suppressions=asan_supp.txt
> >> LSAN_OPTIONS=suppressions=lsan_supp.txt
> >>
> >> 2) properly diagnose unsupported suppressions: e.g. if one will write
> >> thread:foo.cc
> >> and pass this suppression file to UBSan
> >>
> >> 3) get rid of hardcoding all possible sanitizer-specific suppressions in
> >> sanitizer_common.
> >>
> >> I'm fine with making this change, do you agree that we should do it? To
> me
> >> this seems like a no-brainer, but let me know if you think differently.
> >>
> >> --
> >> Alexey Samsonov
> >> vonosmas at gmail.com
>
>
>
> --
> Alexander Potapenko
> Software Engineer
> Google Moscow
>



-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150219/7e87af59/attachment.html>


More information about the llvm-commits mailing list