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. > > --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.
