Re: UBSan suppressions on embedded system

2016-05-12 Thread 'Ilya' via address-sanitizer 
Hey,
I am sorry. Due to your comment I spent some time the last days, digging 
deeper and it turns out the ubsan-message pointed to something else - 
everything fine with the packed structures. Can't believe I failed to see 
that.

However, I still don't understand how the SuppressionContext works for the 
UBSan.

Greetings, and thanks,
Ilya

Am Montag, 9. Mai 2016 11:07:49 UTC+2 schrieb Yuri Gribov:
>
> On Mon, May 9, 2016 at 10:35 AM, 'Ilya' via address-sanitizer 
>  wrote: 
> > 
> >> Worst case you could wrap problematic code in #ifdef 
> >> __SANITIZE_UNDEFINED__ and provide dedicated implementation. What's 
> >> the problem with packed stuff though? 
> > 
> > 
> > Yep, but I'd like to avoid that if possible :) 
>
> Yeah... 
>
> > The packed structures cause "misaligned pointer access". 
>
> Hm, now that sounds as a bug in implementation. Could you file it 
> (with repro) to GCC BZ? 
>
> > -- 
> > 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 address-saniti...@googlegroups.com . 
> > 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 address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: UBSan suppressions on embedded system

2016-05-09 Thread Yuri Gribov 
On Mon, May 9, 2016 at 10:35 AM, 'Ilya' via address-sanitizer
 wrote:
>
>> Worst case you could wrap problematic code in #ifdef
>> __SANITIZE_UNDEFINED__ and provide dedicated implementation. What's
>> the problem with packed stuff though?
>
>
> Yep, but I'd like to avoid that if possible :)

Yeah...

> The packed structures cause "misaligned pointer access".

Hm, now that sounds as a bug in implementation. Could you file it
(with repro) to GCC BZ?

> --
> 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 address-sanitizer+unsubscr...@googlegroups.com.
> 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 address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: UBSan suppressions on embedded system

2016-05-09 Thread 'Ilya' via address-sanitizer 


> Worst case you could wrap problematic code in #ifdef 
> __SANITIZE_UNDEFINED__ and provide dedicated implementation. What's 
> the problem with packed stuff though? 
>

Yep, but I'd like to avoid that if possible :)
The packed structures cause "misaligned pointer access".

-- 
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 address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: UBSan suppressions on embedded system

2016-05-09 Thread 'Ilya' via address-sanitizer 
Hello everybody,

> Usually, ubsan-related questions get answered at  llvm...@lists.llvm.org 
> , we we can reply too :) 
>
 
 first thanks for the quick responses. (We had some national holidays going 
on here, so my answer comes quite late - sorry for that.)

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

Still a WONTFIX :( (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978)
 

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

It's not a "does not work as expected", more a "I don't understand what's 
going on in the sourcecoude".
If I got that right, there's the suppression context, initialized from the 
file on ubsan_init() or rather InitializeSuppressions(). 
However the resultung suppression_ctx object is only used by 
"__ubsan::IsVptrCheckSuppressed". 
So I therefore don't 
really understand how the suppression is working for the other functions. 
This understanding however might be crucial for
me to utilize it to suppress the lasting ubs.

The slowdown could be acceptable, so I'm not worrying about that currently.

Thanks, 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 address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: UBSan suppressions on embedded system

2016-05-03 Thread Konstantin Serebryany 
On Tue, May 3, 2016 at 12:42 PM, 'Alexey Samsonov' via address-sanitizer <
address-sanitizer@googlegroups.com> wrote:

>
> On Tue, May 3, 2016 at 10:49 AM, Konstantin Serebryany <
> konstantin.s.serebry...@gmail.com> wrote:
>
>>
>>
>> On Tue, May 3, 2016 at 1:03 AM, 'Ilya' via address-sanitizer <
>> address-sanitizer@googlegroups.com> 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  llvm-...@lists.llvm.org,
>> 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 address-sanitizer+unsubscr...@googlegroups.com.
>>> 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 address-sanitizer+unsubscr...@googlegroups.com.
>> 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 address-sanitizer+unsubscr...@googlegroups.com.
> 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 address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: UBSan suppressions on embedded system

2016-05-03 Thread Konstantin Serebryany 
On Tue, May 3, 2016 at 1:03 AM, 'Ilya' via address-sanitizer <
address-sanitizer@googlegroups.com> 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  llvm-...@lists.llvm.org,
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 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 address-sanitizer+unsubscr...@googlegroups.com.
> 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 address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.