[PATCH] Allow initialization of Asan interceptors before the general Asan initialization takes place on FreeBSD

[Viktor Kutuzov]

> Could this be solved by initializing interceptors earlier in AsanInit? This initialization sequence is kind of fragile, and I don't like that we arbitrarily move part of it upwards in a platform-dependent way.

By the time when the first of the intercepted functions is called, the libthr (the library Asan's thread rely on on FreeBSD) is being initialized already. AsanInitInternal() initializes both the interceptors and threads unconditionally and thus causes recursive initialization of libthr.

The overall process looks like this:
* the loader calls libthr's .init();
* .init() calls getenv() during initialization of the library;
* genenv() relies on strncmp();
* strncmp() is intercepted, but at this phase the REAL(strncmp) is not yet initialized;
* since Asan is not initialized, AsanInitInternal() takes place;
* AsanInitInternal() initializes the references to the real functions and then call AsanTSDInit();
* AsanTSDInit() calls pthread_key_create();
* pthread_key_create() sees that libthr is not yet initialized (what means its initialization is not yet completed) and launches initialization of libthr.

So the answer to your question is: unfortunately, it doesn't matter how early interceptors get initialized in AsanInitInternal(); the point is that on FreeBSD the initialization of interceptors and initialization of threads are separate phases that cannot be tied together.

http://reviews.llvm.org/D4496