This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [asan] Emit GIMPLE directly, small cleanups
On Fri, Oct 12, 2012 at 12:15 AM, Jakub Jelinek <jakub@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