Another error checking feature is to poison stack vars on entry and
exit of the lexical scope to catch uninit variable reference and out
of scope references:
S* sp;
{
S s;
sp = &s;
}
.. *sp ...
This is relatively easy to do in gcc thanks to the clobber statement.
In Clang/LLVM, it is in the wishlist:
http://code.google.com/p/address-sanitizer/issues/detail?id=83
Might be good consider this feature.
David
On Fri, Oct 12, 2012 at 9:30 AM, Xinliang David Li <davi...@google.com> wrote:
> On Fri, Oct 12, 2012 at 12:15 AM, Jakub Jelinek <ja...@redhat.com> wrote:
>> On Thu, Oct 11, 2012 at 04:19:18PM -0700, Wei Mi wrote:
>>> Here is the initial test results of gcc asan patch, and it shows us
>>> some missing features in gcc but existing in llvm.
>>> [1]. gcc regression test for gcc-asan passes.
>>> [2]. llvm regression tests for gcc-asan: 18 failures in 123 for tests
>>> written in google test and 24 failures in 28 for tests written in lit
>>> tests.
>>>
>>> gcc missing features:
>>
>> I think LLVM calls the option -faddress-sanitizer, perhaps we should rename
>> -fasan to that too for some compatibility. For the varios knobs LLVM asan
>> has we could add params to params.def if we want to support them.
>>
>>> 1. gcc implementation doesn't support stack/global overflow check
>>
>> Yeah, I think the stack check shouldn't be that hard and can hack it up,
>> I'll perhaps leave the global vars stuff to Dodji or others if he has time.
>
> Since the stack part is relative self contained, might it be better
> for Wei (he is new) to tackle it with guidance from you?
>
> Global handling needs people more experienced with varasm stuff.
>
>>
>>> 1. gcc implementation doesn't support some attributes, such as
>>> __attribute__((no_address_safety_analysis)), which llvm does
>>
>> Yeah, shouldn't be hard.
>>
>
> yes -- that is simple.
>
>
>>> 2. gcc doesn't detect out-of-bound bitfield access of heap, which llvm does
>>
>> Testcase (for everything testcases would be useful, and of course the
>> runtime library too)? Yeah, the code currently punts on those, the question
>> is how to handle them.
>
> The code should sythensize the smallest containing
> byte/word/doubleword/qword of the bitfield and then compute the shadow
> address.
>
>>
>>> 3. gcc doesn't detect out-of-bound memset, memcopy, strcat and strcpy
>>> for heap allocated memory or string, which llvm does
>>
>> That is easy (we can easily handle instrumenting lots of builtins).
>> Just a big switch on DECL_FUNCTION_CODE, collecting src/dst addresses and
>> length for each of them and adding the instrumentation for first and last
>> bytes in the strings.
>
> Yes.
>
>>
>>> 4. gcc doesn't contain similar options: -mllvm -asan-blacklist, -mllvm
>>> -asan-initialization-order
>>
>> I must say I don't like the -asan-blacklist option at all, IMHO it is much
>> saner to just ask users to use attributes (or pragmas around whole headers).
>
> But the option is easy to have too.
>
>>
>>> 5. gcc -fasan doesn't take effect at -O0, but llvm does. Most lit
>>> tests contain checks from -O0 to -O3, which makes gcc fail.
>>
>> That is because of the place where the instrumentation is scheduled right
>> now in the pass queue. We can easily add a pass_asan_O0 that will run say
>> close to pass_lower_complex_O0.
>
> Right.
>
> thanks,
>
> David
>>
>> Jakub
