On 03 Aug 2016, at 20:44, Renato Golin <renato.go...@linaro.org> wrote: > > On 3 August 2016 at 19:24, Dimitry Andric via cfe-dev > <cfe-...@lists.llvm.org> wrote: >> Unfortunately this is in TSan, which does not work at all on FreeBSD 11 and >> higher, due to a conflict of initialization order with our jemalloc. So I >> am not extremely keen on fixing this before the release. > > This sounds really serious. Do we have a bug for that?
I'm not sure if it should be a compiler-rt bug or a FreeBSD bug. The issue is
that __tsan_init() should be called before the initialization of malloc(), and
that is not possible (or extremely difficult) with the version of jemalloc in
FreeBSD 11 and 12.
The mechanism that TSan uses appears to be a .preinit_array section (though I'm
not 100% sure it is used on FreeBSD):
__attribute__((section(".preinit_array"), used))
void (*__local_tsan_preinit)(void) = __tsan_init;
This section is then statically linked into the executable. However, jemalloc
initializes through a constructor in libc.so:
JEMALLOC_ATTR(constructor)
static void
jemalloc_constructor(void)
{
malloc_init();
}
Since .so files which are required by an executable are *always* loaded and
initialized before that executable, certainly for the .preinit_array section
and the constructors, I am unsure how to solve this race. Maybe the solution
is to link a small .so into the executable which is loaded even earlier than
libc.so?
In the past I have tried several ways of working around this, could never get
it to work, and then dropped it due to other priorities. But if anybody has
good ideas, I am all ears. :-)
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
