On Tue, May 3, 2016 at 8:49 PM, 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..).
Worst case you could wrap problematic code in #ifdef
__SANITIZE_UNDEFINED__ and provide dedicated implementation. What's
the problem with packed stuff though?
>> 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 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.
>
> --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.
--
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.
