On Tue, May 3, 2016 at 12:42 PM, 'Alexey Samsonov' via address-sanitizer <
[email protected]> wrote:

>
> On Tue, May 3, 2016 at 10:49 AM, Konstantin Serebryany <
> [email protected]> wrote:
>
>>
>>
>> On Tue, May 3, 2016 at 1:03 AM, 'Ilya' via address-sanitizer <
>> [email protected]> wrote:
>>
>>> Hello everybody,
>>> first of all: thanks for reading. I have questions regarding the
>>> UndefinedBehaviourSanitizer and didn't know where else to post them.
>>>
>>
>> Usually, ubsan-related questions get answered at  [email protected],
>> we we can reply too :)
>>
>>
>>
>>>
>>> I am currently working on an embedded system project, porting the UBSan
>>> RTL (GCC) to work with our stuff. After lots of ripping out this works,
>>> with a few side effects though (for example no support for flags in the RTL
>>> (yet)). To make this work in a long perspective I'd like to get rid of all
>>> current ubs. However, since low-level stuff is low-level, we have some
>>> occurrences of ub which are to be accepted and will last (a few null
>>> pointer dereferences, packed structures, etc..). I figured out how to get
>>> rid of some warnings (function-wise attributes),
>>>
>>
>> You mean, __attribute__((no_sanitizer("your-but-type"))), right?
>> That's the best.
>>
>>
>>> but this won't help with for example the packed structures.
>>>
>>> So I want to suppress the warnings in a few occasions. I however can't
>>> figure out, how exactly issue suppression (other than function-wise via
>>> attributes) works in the UBSan. I do see the suppression context being
>>> created, with the file being parsed. However the only usage of that in the
>>> UBSan I can find is the "IsVptrCheckSuppressed" function.
>>>
>>> So, main questions:
>>> Which file described in the Clang documentation is being parsed into the
>>> suppression context? (fsanitize-blacklist, or UBSAN_OPTIONS=suppressions
>>> =MyUBSan.supp ?)
>>>
>>
>> fsanitize-blacklist is a compile-time suppression mechanism -- the code
>> in the blacklist is not instrumented.
>> This would have been preferable, but AFIACT, gcc does not support this
>> flag. (correct me if I am wrong).
>>
>>
>>
>>> Is the suppression context used in another way that I don't see?
>>>
>>
>
>
>>
>>> And how is the other file used then?
>>>
>>
>> I am not sure I understand your question about
>> UBSAN_OPTIONS=suppressions=MyUBSan.supp
>> If you can provide a small example where something does not work as
>> expected (with the fresh clang) we can take a look.
>>
>
> Note that the fresh Clang has way better support for runtime suppressions,
> and allows you to suppress issues by the error kind.
>
>
>> Note that UBSAN_OPTIONS=suppressions=... is a run-time option and if you
>> hit the bug you are going to suppress very often
>> the suppression will slow down the run significantly.
>>
>
> No, I believe UBSan report deduplication would kick in here: when we first
> try to print an error report associated with a PC, we will
> check if it should be suppressed (this can be expensive, as it might
> require symbolization). All further attempts to report the same error
> would be silently and quickly ignored.
>

quickly is in "quicker than the first time".
Still pretty slow if you have a report in a hot spot.


>
>
>>
>> --kcc
>>
>>>
>>> Thank you, for taking the time and the great tools,
>>> Ilya
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "address-sanitizer" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "address-sanitizer" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Alexey Samsonov, Mountain View, CA
>
> --
> You received this message because you are subscribed to the Google Groups
> "address-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to