asan: allow __asan_{before,after}_dynamic_init without registered globals
authorDmitry Vyukov <dvyukov@google.com>
Mon, 5 Sep 2016 12:22:56 +0000 (12:22 +0000)
committerDmitry Vyukov <dvyukov@google.com>
Mon, 5 Sep 2016 12:22:56 +0000 (12:22 +0000)
commit3c503d1b5228d655a0fe118a4b4a22997aab97bf
treef47a8cc8590fd5f02d75c3a1ab7889a86af3c9c5
parentef0a45aaa5b0afff6e3812bd533f151e1ca9ba36
asan: allow __asan_{before,after}_dynamic_init without registered globals

When optimizing, GCC optimizes away aggressively unused static globals.
The __asan_before_dynamic_init/__asan_after_dynamic_init calls are placed
in static constructor earlier while the registration of the globals is done
later in the compilation process.  If all the globals with
dynamic initialization are optimized away from some particular TU in between
those two, libasan can fail on an assertion that dynamic_init_globals is
empty.

While I'm going to commit a GCC change which will remove the
__asan_before_dynamic_init/__asan_after_dynamic_init in many cases when this
happens (basically if the optimizers can prove there are no memory
references in between the two calls), there are still testcases where such
pair of calls is left, e.g. for
struct S { S () { asm volatile ("" : : : "memory"); } };
static S c;

int
main ()
{
  return 0;
}
with -O2 -fsanitize=address and ASAN_OPTIONS=check_initialization_order=true
this still fails the assertion.  Trying to avoid this problem on the
compiler side would decrease code quality I'm afraid, whether it is making
sure for -fsanitize=address we keep around at least one dynamically
initialized global if the
__asan_before_dynamic_init/__asan_after_dynamic_init pair has been emitted,
or adding some artificial global which would be used as the condition for
those calls etc.
So, can the assertion be instead just removed, this really shouldn't slow
down the calls measurably (for __asan_before_dynamic_init it is even
cheaper) and the assertion doesn't check something worthwhile anyway (it is
sufficient if there is a single dynamically initialized global in any other
TU to make it happy).

Details in http://gcc.gnu.org/PR77396

Author: Jakub Jelinek
llvm-svn: 280657
compiler-rt/lib/asan/asan_globals.cc