[LLVMdev] r139934 requires (correct?) code organization changes

[Garrison Venn]

I've tracked down a problem I've been having with llvm code ensconced in shared
libraries that priori to r139934, on OS X 10.7.1-10.7.2 worked fine. Since r139934, 
which involves a configure change (and configure.ac), resulting in the default clang
compiler to be used when building clang, and llvm, it seems I can no longer deposit
llvm code involving jit, and IR gen functionality into shared libraries, if the translation
unit containing main also contains such features. For example using the attached
files, place externalVerify.cpp into a dynamic shared library, and build createAndVerifyFunctionTest.cpp
against it. Running it (with asserts on) creates:

Two passes with the same argument (-domtree) attempted to be registered!
UNREACHABLE executed at <root dir>/llvm/include/llvm/Support/PassNameParser.h:73!

Prior to patch r139934 (prior to the default platform's installed clang building clang 
and llvm), this example works fine. From a llvm pass internals perspective this is 
because PassNameParser::passRegistered(...) tries to add a new option containing
info for a pass; in this case the DominatorTree pass. The state of the system asserts
because a DominatorTree pass option has already been created. This is perplexing since 
this means that the atomic compare and swap operation on static var "initialized" 
contained in CALL_ONCE_INITIALIZATION(...) did not prevent the pass's associated 
initialize""PassOnce(...) function from being invoked more than once. Logically, baring 
other knowledge, the only way this can happen is that CALL_ONCE_INITIALIZATION(...) 
is instantiated in at least two places. Although I forced the example to exemplify the issue 
for the DominatorTree pass, this problem has nothing to do with this pass specifically.

Given that when directly linking the example's createAndVerifyFunctionTest.o with 
externalVerify.o, does not manifest the issue, the above means that using a shared
library, with such a main, is the incorrect way to organize such projects. Is this correct?
Should I be now using static libs instead? Please note that the example is NOT
directly registering a pass, in fact up till now, for this example, I've only be able to generate 
this pass registration conflict by having the main translation unit include llvm/ExecutionEngine/JIT.h.
As doing the manual svn bijection effort to locate the commit was a slow process, I
thought I would go to the list for help (I have real code which organizes its files with
shared libraries), to short cut to a solution--finding out why a clang (platform dependent?),
built clang/llvm manifests the issue would be another long effort.

My platform's (OS X 10.7.2), default clang is:

Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

The clang/llvm I used to build my example is at (r143900)

Thanks in advance

Garrison

-------------- next part --------------
A non-text attachment was scrubbed...
Name: createAndVerifyFunctionTest.cpp
Type: application/octet-stream
Size: 1771 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111107/abd4965d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: externalVerify.cpp
Type: application/octet-stream
Size: 594 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111107/abd4965d/attachment-0001.obj>
-------------- next part --------------