[Openmp-dev] [cfe-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged

[Dimitry Andric via Openmp-dev]

On 03 Aug 2016, at 20:44, Renato Golin <renato.golin at linaro.org> wrote:
> 
> On 3 August 2016 at 19:24, Dimitry Andric via cfe-dev
> <cfe-dev at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20160803/e6943739/attachment.sig>