gcc version 4.8.2 (Debian 4.8.2-16) gcc test.c -O2 -fsanitize=address -o test int depth = 3; //int testGlobalOutOfBoundsRODATAVar[2] = {1}; /* data: works (asan_report_load4 present) */ const int testGlobalOutOfBoundsRODATAVar[1] = {1}; /* rodata: doesn't work (no asan_report_load4 present) */ //int testGlobalOutOfBoundsRODATAVar[1] = {0}; /* bss : works (asan_report_load4 present) */ //int testGlobalOutOfBoundsRODATAVar[1]; /* bss : doesn't work !??? (asan_report_load4 present!) */ int test(void) { return testGlobalOutOfBoundsRODATAVar[depth]; // boom } int main(void) { return test(); }
Will adding "-fno-common" help? Or building the test as C++? See https://code.google.com/p/address-sanitizer/wiki/Flags
Using -fno-common (while compiling as C), or compiling as C++ works for the unitialized bss example: int testGlobalOutOfBoundsRODATAVar[5]; /* bss : works with -fno-common (compiled as C) or when compiled as C++ */ but not for the .rodata example.
I can reproduce this in trunk. Looks like Asan pass works correctly but gcc reduces test() to 'return 1;' very early for some reason. I'll debug further.
(In reply to Yury Gribov from comment #3) > I can reproduce this in trunk. Looks like Asan pass works correctly but gcc > reduces test() to 'return 1;' very early for some reason. I'll debug further. Most likely due to GCC optimizing the code as it knows the only value it could be is 1. Try it with a two element constant array and you most likely get the result you want.
(In reply to Andrew Pinski from comment #4) > (In reply to Yury Gribov from comment #3) > > I can reproduce this in trunk. Looks like Asan pass works correctly but gcc > > reduces test() to 'return 1;' very early for some reason. I'll debug further. > > Most likely due to GCC optimizing the code as it knows the only value it > could be is 1. Yup, testGlobalOutOfBoundsRODATAVar[depth] is cynically folded to 1 right in the gimplifier: #0 fold_array_ctor_reference (type=0x7ffff6c93000, ctor=0x7ffff6c7ae28, offset=0, size=32, from_decl=0x7ffff6c91098) at /home/ygribov/src/gcc-master/gcc/gimple-fold.c:2994 #1 0x00000000007fbc4b in fold_ctor_reference (type=0x7ffff6c93000, ctor=0x7ffff6c7ae28, offset=0, size=32, from_decl=0x7ffff6c91098) at /home/ygribov/src/gcc-master/gcc/gimple-fold.c:3124 #2 0x00000000007fc1b4 in fold_const_aggregate_ref_1 (t=0x7ffff6c35188, valueize=0) at /home/ygribov/src/gcc-master/gcc/gimple-fold.c:3226 #3 0x00000000007fc2d7 in fold_const_aggregate_ref (t=0x7ffff6c35188) at /home/ygribov/src/gcc-master/gcc/gimple-fold.c:3248 #4 0x00000000007f2478 in maybe_fold_reference (expr=0x7ffff6c35188, is_lhs=false) at /home/ygribov/src/gcc-master/gcc/gimple-fold.c:310 #5 0x00000000007f2957 in fold_gimple_assign (si=0x7fffffffd1f0) at /home/ygribov/src/gcc-master/gcc/gimple-fold.c:377 #6 0x00000000007f57a2 in fold_stmt_1 (gsi=0x7fffffffd1f0, inplace=false) at /home/ygribov/src/gcc-master/gcc/gimple-fold.c:1281 #7 0x00000000007f5eba in fold_stmt (gsi=0x7fffffffd1f0) at /home/ygribov/src/gcc-master/gcc/gimple-fold.c:1409 #8 0x00000000008115d1 in maybe_fold_stmt (gsi=0x7fffffffd1f0) at /home/ygribov/src/gcc-master/gcc/gimplify.c:2224 #9 0x000000000081af78 in gimplify_modify_expr (expr_p=0x7fffffffd4a8, pre_p=0x7fffffffd760, post_p=0x7fffffffd330, want_value=false) at /home/ygribov/src/gcc-master/gcc/gimplify.c:4620 #10 0x0000000000826bf4 in gimplify_expr (expr_p=0x7fffffffd4a8, pre_p=0x7fffffffd760, post_p=0x7fffffffd330, gimple_test_f=0x819e8b <is_gimple_stmt(tree)>, fallback=0) at /home/ygribov/src/gcc-master/gcc/gimplify.c:7479 This kind of makes sense (although this optimization will break in presence of LD_PRELOAD or weak symbols). In any case optimizations like this are typical for gcc so I'm not sure there's a chance for a fix.
None of these is an asan bug, closing. Feel free to reopen if you disagree.
I'd say it is fine for test to be optimized to 1 at -O2, but am not sure we want to do that even for -O0 (and if we disable it for -O0, whether we want it for -Og). Then it will be user's choice whether he wants to instrument optimized code (where there is no out of bound access), or non-optimized code (where there would be out of bounds access).