On 10/18/2017 11:16 AM, Jakub Jelinek wrote:
> On Wed, Oct 18, 2017 at 11:00:30AM +0200, Martin Liška wrote:
>> Hi.
>>
>> I would like to use this thread to slightly describe differences in GCC and
>> LLVM.
>> I compared options support by both and:
>>
>> UBSAN:
>>
>> 1)
>> gcc: error: unrecognized argument to -fsanitize= option: ‘nullability-arg’
>> gcc: error: unrecognized argument to -fsanitize= option: ‘nullability-assign’
>> gcc: error: unrecognized argument to -fsanitize= option: ‘nullability-return’
>
> I believe those are for diagnostic of some Objective-C addition, some
> _Nullable and _Nonnull keywords on (pointer) types. Seems LLVM supports it
> as an
> extension even for C/C++.
Ok.
>
>> I guess it's covered by -fsanitize=nonnull-attribute and
>> -fsanitize=returns-nonnull-attribute.
>> One can't have in GCC a local variable with non-null attribute
>> (nullability-assign), right?
>>
>> 2) unsigned-integer-overflow
>>
>> As documented, not being a real UBSAN. Do we want that or seen as not useful?
>
> This one is not implemented on purpose, it doesn't make any sense to me.
Works for me.
>
>> 3) function
>>
>> Indirect function pointer comparison using RTTI in C++. Would it be useful?
>> Ideas?
>
> Dunno what this one is about.
$ cat indir.cpp
void foo(void) { }
struct A
{
static int bar(void) { return 0; }
};
void call (int (*f) (void))
{
f();
}
int main()
{
A a;
call ((int (*) (void))&foo);
}
$ ~/bin/llvm/bin/clang++ -fsanitize=function /tmp/indir.cpp && ./a.out
/tmp/indir.cpp:10:3: runtime error: call to function foo() through pointer to
incorrect function type 'int (*)()'
(/tmp/a.out+0x42b9b0): note: foo() defined here
>
> 4) builtin
>
> Which I've posted yesterday patch for.
I noticed, thanks!
>
>> ASAN:
>>
>> For ASAN, there's quite up-to-date page:
>> https://github.com/google/sanitizers/wiki/AddressSanitizerClangVsGCC-(5.0-vs-7.1)
>>
>> The page is quite up-to-date. Currently we should cover all what LLVM
>> supports. Am I right? Or is there any interesting
>> feature we miss?
>
> As I said on IRC, we probably should be redirecting at sanopt or asan pass
> __builtin_memcpy etc. calls to __asan_memcpy etc.
I'll take a look.
Martin
>
> Jakub
>
