On 2012-10-11 19:19 , Wei Mi wrote:> Hi,
>
> 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:
> 1. gcc implementation doesn't support stack/global overflow check
> 1. gcc implementation doesn't support some attributes, such as
> __attribute__((no_address_safety_analysis)), which llvm does
> 2. gcc doesn't detect out-of-bound bitfield access of heap, which
llvm does
> 3. gcc doesn't detect out-of-bound memset, memcopy, strcat and strcpy
> for heap allocated memory or string, which llvm does
> 4. gcc doesn't contain similar options: -mllvm -asan-blacklist, -mllvm
> -asan-initialization-order
> 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.
> 6.
$HOME/llvm/trunk/projects/compiler-rt/lib/asan/scripts/asan_symbolize.py
> could generate valid source locations from virtual addresses for llvm
> binary, but fail to do that for gcc binary. example, llvm result #1
> 0x402694 in main heap-overflow.cc:23 .vs. gcc result: #1 0x402694 in
> main ??:0. Some FileCheck in llvm lit tests expect the valid source
> locations.
Thanks for the analysis Wei.
We need to decide what's the best way of dealing with the runtime. My
inclination is to treat it the same way we treat gmp, mpfr, et al:
1- If libasan/ exists, we enable asan as a feature at configure time.
2- libasan/ is always a pristine copy of the LLVM repository. We could
have tarballs in ftp://gcc.gnu.org/pub/gcc/infrastructure/ which are
brought in by contrib/download_prerequisites.
3- To run ASAN's testsuite, I propose a simple wrapper script that
executes it using the just-built gcc. I don't think it's worth the pain
to convert the testsuite into DejaGNU.
Comments?
Thanks. Diego.
